From nobody Fri Sep 5 04:43:13 2025 X-Original-To: dev-commits-src-main@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4cJ3cx5mBnz673wT; Fri, 05 Sep 2025 04:43:13 +0000 (UTC) (envelope-from jamie@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R13" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cJ3cx4sH9z3dDX; Fri, 05 Sep 2025 04:43:13 +0000 (UTC) (envelope-from jamie@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1757047393; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=xIuma+Z/hKjGT3ehL/jzF6GzGIiLWgLCHOMLXcUKANs=; b=eu7pj4aafy5YpHpp8w81n+sVEh14cyycbbGdClYzXX49mY+4jeBKf1ZbmA6ELTpYI+bKFP i0xx8BdeRAoZCIBHZr4KVZZDO77+0ALGRZFLupkseFplkAokfc/J+NX4Zn7eIK4/FZxeTb 1a5uzw09M6WugNwcNHVXMAXzBTYUjefbDFtOAwkLXjFQrw32iIX30c+Jmj/KT9M8nNkCiZ 3jub463Lrk2+Soz+OAQNaagIk4gTHuKssi2BfovS5x6EfIcg0Y8F8G67rqB9C/B+EHF2lm h+yIgggJ6mkO2idTsKkVv9u5aAvDw73h6ZoalG9g9jcS5Qa2s2WhVl68n6TvSQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1757047393; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=xIuma+Z/hKjGT3ehL/jzF6GzGIiLWgLCHOMLXcUKANs=; b=MTLi84u7wrsf6ywzkom9R+pHcaxrz+Ao4O9ZaNbPEDVEGt1LVCpRXZMSOLM8C73CkU/h3y sF4KLh6UOfl8sGj6QEW/LrMtNFw+Q9XH5N0JrNwh8kQNmZxAUB+AS6k1pkTxH8NwQlR+jZ Jwb4xv0i49fRIvdaLOlUm+o7DuA9Bv/EC/Y/Hv42Xk/fLZ2Oot9hb1zesMP/xsEHv0vHuL H9+pIi9LiUsJ3lQpHkka4D8BFcmf86rocWM9m7p2ttBJfR/zokk2WIvzqgPGv6qwCU99aZ nfZEmGW7Qvi44Hv57Y5WLXfFdCB1HpW1USvleA6q45qTaKk/FMzMVkWA59kV9A== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1757047393; a=rsa-sha256; cv=none; b=fTwb580Q33pMauFkQLpvRLiiRXi9EWQFlel8emQU+frNNbnrInYELaJOibTy/iLBy2njek MCyuYTUspDW+SU59hmfT6WfCStX6NM/B7YZbIq148J9ufgR5FvVXQyJjVHHhzbTamFpgAT 5kvF15NV1eFvnKKpGCySyytL1KyAK4Yy7ggSTMu+4k4X6lRJ8DYrnepPEzRv+kVNhg570X jcT4yQc52H3pXxnCHyP4ErvAp7hgH6bvVBWSfQxrbDBxH0tAmzV//GCnnVW+7tfmKylbpB es4sq9UwecdRpWPC/dO2aPSlfYQWzPfNPeECLwr7u9quQrgztNSXE9IakKEIBQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from m2.gritton.org (gritton.org [67.43.236.212]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: jamie) by smtp.freebsd.org (Postfix) with ESMTPSA id 4cJ3cx43w2zmQm; Fri, 05 Sep 2025 04:43:13 +0000 (UTC) (envelope-from jamie@freebsd.org) Received: from gritton.org (localgritton [127.0.0.212]) by m2.gritton.org (Postfix) with ESMTPSA id 410607967C; Thu, 4 Sep 2025 21:43:13 -0700 (PDT) List-Id: Commit messages for the main branch of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-main List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: dev-commits-src-main@freebsd.org Sender: owner-dev-commits-src-main@FreeBSD.org MIME-Version: 1.0 Date: Thu, 04 Sep 2025 21:43:13 -0700 From: James Gritton To: Konstantin Belousov Cc: src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org Subject: Re: git: 851dc7f859c2 - main - jail: add jail descriptors In-Reply-To: References: <202509042031.584KVpxY000408@gitrepo.freebsd.org> Message-ID: X-Sender: jamie@freebsd.org Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 2025-09-04 16:43, Konstantin Belousov wrote: > On Thu, Sep 04, 2025 at 08:31:51PM +0000, Jamie Gritton wrote: >> The branch main has been updated by jamie: >> >> URL: >> https://cgit.FreeBSD.org/src/commit/?id=851dc7f859c23cab09a348bca03ab655534fb7e0 >> >> commit 851dc7f859c23cab09a348bca03ab655534fb7e0 >> Author: Jamie Gritton >> AuthorDate: 2025-09-04 20:27:47 +0000 >> Commit: Jamie Gritton >> CommitDate: 2025-09-04 20:27:47 +0000 >> >> jail: add jail descriptors >> >> Similar to process descriptors, jail desriptors are allow jail >> administration using the file descriptor interface instead of >> JIDs. >> They come from and can be used by jail_set(2) and jail_get(2), >> and there are two new system calls, jail_attach_jd(2) and >> jail_remove_jd(2). >> >> Reviewed by: bz, brooks > > The code is from jaildesc_alloc(): > > jd = malloc(sizeof(*jd), M_JAILDESC, M_WAITOK | M_ZERO); > error = falloc_caps(td, &fp, fdp, 0, NULL); > finit(fp, priv_check_cred(fp->f_cred, PRIV_JAIL_SET) == 0 > ? FREAD | FWRITE : FREAD, DTYPE_JAILDESC, jd, &jaildesc_ops); > ^^^^^^^^^^^ '?' should be placed on the previous line I wasn't aware of this requirement; style(9) is silent on it. > if (error != 0) { > free(jd, M_JAILDESC); > return (error); > } > If falloc_caps() returned error, fp does not point to a valid file. > Then finit() operates on random memory. I'll file a fix for that. The error check just needs to be moved up. > Generated files should have been committed as a follow-up, not in the > same commit as written code. The FreeBSD Wiki explicitly allows it in the same commit. > jaildesc_find() returns EBADF when passed file type is not DTYPE_JAIL. > Normally EBADF means that the object underlying the file is > invalidated, > like vnode is reclaimed, tty is revoked, etc. For the wrong type, > EINVAL > should be returned. That's part of the code that I lifted from process descriptors, nearly identical to procdesc_find. A check of other c_type checks shows EBADF isn't uncommon. > jaildesc_close() does > finit(fp, 0, DTYPE_NONE, NULL, &badfileops); > that is not needed, same as cleaning f_data. Yes, that's appears to be overkill, considering it should only be called when the descript is about to be deallocated anyway. I'll remove that. > There are fo_chown/fo_chmod methods that are semantically applied to > the > jail files, instead of the underlying object. This is quite strange, > files > do not have concept of owner. True, it is strange. But jails don't have owners either, and this seemed a good way to control how the descriptors could be used. I see the jail descriptor as an intermediate object between the jail and the file descriptors, like there's a portal to the jail that is owned by its creator, and the file descriptor returned is merely the access to that portal. It's roughly equivalent to a temp file that doesn't exist in the filesystem directory space after its creation, yet is still a thing with ownership and permissions. I could remove this if it's too far out of mainstream practice, but I hope not to have to, since it provides a handy to allow some to (for instance) attach to a prison, but not alter or remove it. Such things are perhaps better left to Capsicum, but I don't have that support in place yet. - Jamie