From nobody Sat Sep 6 02:32:48 2025 X-Original-To: dev-commits-src-all@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 4cJch76C6kz66nGb; Sat, 06 Sep 2025 02:32:55 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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) by mx1.freebsd.org (Postfix) with ESMTPS id 4cJch74RMxz3Pry; Sat, 06 Sep 2025 02:32:55 +0000 (UTC) (envelope-from kostikbel@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: from tom.home (kib@localhost [127.0.0.1] (may be forged)) by kib.kiev.ua (8.18.1/8.18.1) with ESMTP id 5862Wm98020025; Sat, 6 Sep 2025 05:32:51 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 5862Wm98020025 Received: (from kostik@localhost) by tom.home (8.18.1/8.18.1/Submit) id 5862Wmm3020024; Sat, 6 Sep 2025 05:32:48 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 6 Sep 2025 05:32:48 +0300 From: Konstantin Belousov To: James Gritton 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 Message-ID: References: <202509042031.584KVpxY000408@gitrepo.freebsd.org> <24bbb82cec2509bcfe1d8514500367ab@freebsd.org> List-Id: Commit messages for all branches of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: dev-commits-src-all@freebsd.org Sender: owner-dev-commits-src-all@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <24bbb82cec2509bcfe1d8514500367ab@freebsd.org> X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=4.0.1 X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on tom.home X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4cJch74RMxz3Pry On Fri, Sep 05, 2025 at 10:34:18AM -0700, James Gritton wrote: > On 2025-09-04 22:14, Konstantin Belousov wrote: > > On Thu, Sep 04, 2025 at 09:43:13PM -0700, James Gritton wrote: > > > On 2025-09-04 16:43, Konstantin Belousov wrote: > > > > 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. > > > > Naturally, you would added a jail owner (ucred), and make fo_chown > > change the owner then. I quite dislike trying to strength filesystem > > DACs > > to jail access control. > > You're not the first to object to this repurposing of of permission > bits. I guess the proper thing to do is to get the Capsicum support > in place, and use that instead. So this hack may well be going away > soon. Well, I am not objecting assigning some permission and giving access control over the jail's manipulations ops. My claim is that trying to overload fs ownership and related syscalls to do it for different objects (jails) is not correct. If you lower the ownership down to the jail object itself, from the file object (which is not appropriate place), and then provide specific semantic for fchmod/fchown, it is debatable. But the the current state should not be left until some undetermine future.