Re: git: 851dc7f859c2 - main - jail: add jail descriptors

From: Konstantin Belousov <kostikbel_at_gmail.com>
Date: Sat, 06 Sep 2025 02:32:48 UTC
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.