Re: Extended "system" attributes within jailed environment dont work
Konstantin Belousov wrote: >On Fri, Jul 14, 2017 at 07:28:58PM +1000, Dewayne Geraghty wrote: [stuff snipped] >> >> I suppose that the crux to the question is - why should the "system" >> namespace not be available within a jail? >Perhaps because system namespace (can) carry attributes which modify the >filesystem behaviour in a way which is considered inappropriate to allow >for jailed root. This is somewhat similar to jail security.allow_chflags >knob, but with more unfortunate consequences. > >I do not claim that system namespace cannot be opened to the jailed root, >but doing so requires a review of all implemented system ext attributes, >across all types of filesystems. One *hackish* way to deal with this might be to have the attribute created within the "user" namepsace with "system." prepended to it's name when within a jail. - That would allow SAMBA (and others) set/get attributes that they specify as "system namespace", but the attributes wouldn't actually be in "system namespace". Although the patch never ended up in head as yet, there was a similar issue w.r.t. extended attribute namespace for fuse filesystems, since fuse doesn't support the notion of a namespace. Just a suggestion. I have no strong opinion on this, rick ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Extended "system" attributes within jailed environment dont work
On Fri, Jul 14, 2017 at 07:28:58PM +1000, Dewayne Geraghty wrote: > On 14/07/2017 5:56 PM, Konstantin Belousov wrote: > > On Fri, Jul 14, 2017 at 01:53:40PM +1000, Dewayne Geraghty wrote: > >> Can someone advise how I can enable extended attributes in a "system" > >> namespace within a jailed (or bhyve) environment? There was no guidance > >> in "man jail" nor "man jail.conf". > > Mentioning jails and bhyve in a single sentence clearly indicates serious > > issues with understanding either feature. > > Hmm. > > > > >> > >> Simple test > >> >From the host or base system: > >> # touch /a ; setextattr user t1 first /a ; getextattr user t1 /a > >> /a first > >> # touch /a ; setextattr system t2 second /a ; getextattr system t2 /a > >> /a second > >> > >> Within a jail: > >> # touch /a ; setextattr user t1 first /a ; getextattr user t1 /a > >> /a first > >> # touch /a ; setextattr system t2 second /a ; getextattr system t2 /a > >> setextattr: /a: failed: Operation not permitted > >> getextattr: /a: failed: Operation not permitted > >> > >> The impact of this is that SAMBA after 4.3 uses "system" namespace > >> extended attributes; hence can not provision an Active Directory within > >> a jailed environment. (For the inclined, this affects sysvol, and > >> interestingly "rsync -x" is unable to copy extended attributes, so > >> having consistent sysvols across a SAMBA domain may be a challenge) > > System namespace access is not allowed for jailed processes by design. > > See sys/kern/vfs_subr.c:extattr_check_cred() and a comment there > > explicitely mentioning the behaviour. The behaviour predates ~ year > > 2002, where extended attributes were introduced, and it makes sense. > > Thank-you for the pointer to the source. With the passage of 15 years > other applications have come to use "system" namespace extended > attributes, as though they were in the host system. Unfortunately if > you have one physical box available to act as both an authentication > server (Quasi Active Directory) and a fileserver, then using a jailed > environment is the only solution. > > By design? I suppose its akin to saying, why would you want to use > sysvipc from within a jail, with its global namespace (since FreeBSD > V5.0) ; or perhaps the use of raw sockets (FreeBSDv6.0); or mount within > a jail (FreeBSD V9.0); or...? > Probably because sophisticated use of jails is one of the many > outstanding features that sets FreeBSD apart from restrictive and > antiquated environments. Not all features of a base system should be > reflected in a jail, that would be silly; but where upstream > applications use features, then the enhancement of a jail's > configuration via way of, at least, an option - makes sense. Doesn't it? > > I suppose that the crux to the question is - why should the "system" > namespace not be available within a jail? Perhaps because system namespace (can) carry attributes which modify the filesystem behaviour in a way which is considered inappropriate to allow for jailed root. This is somewhat similar to jail security.allow_chflags knob, but with more unfortunate consequences. I do not claim that system namespace cannot be opened to the jailed root, but doing so requires a review of all implemented system ext attributes, across all types of filesystems. > > Aside: Someone on the SAMBA mailing list also using FreeBSD has a > similar problem, but he's using bhyve - hence the use within the same > sentence. This cannot be related, obviously. Bhyve is a hypervisor which runs a full instance of the kernel in VM, so again, claiming that the issue is same while mixing jails and bhyve is indicative. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Extended "system" attributes within jailed environment dont work
On 14/07/2017 5:56 PM, Konstantin Belousov wrote: > On Fri, Jul 14, 2017 at 01:53:40PM +1000, Dewayne Geraghty wrote: >> Can someone advise how I can enable extended attributes in a "system" >> namespace within a jailed (or bhyve) environment? There was no guidance >> in "man jail" nor "man jail.conf". > Mentioning jails and bhyve in a single sentence clearly indicates serious > issues with understanding either feature. Hmm. > >> >> Simple test >> >From the host or base system: >> # touch /a ; setextattr user t1 first /a ; getextattr user t1 /a >> /a first >> # touch /a ; setextattr system t2 second /a ; getextattr system t2 /a >> /a second >> >> Within a jail: >> # touch /a ; setextattr user t1 first /a ; getextattr user t1 /a >> /a first >> # touch /a ; setextattr system t2 second /a ; getextattr system t2 /a >> setextattr: /a: failed: Operation not permitted >> getextattr: /a: failed: Operation not permitted >> >> The impact of this is that SAMBA after 4.3 uses "system" namespace >> extended attributes; hence can not provision an Active Directory within >> a jailed environment. (For the inclined, this affects sysvol, and >> interestingly "rsync -x" is unable to copy extended attributes, so >> having consistent sysvols across a SAMBA domain may be a challenge) > System namespace access is not allowed for jailed processes by design. > See sys/kern/vfs_subr.c:extattr_check_cred() and a comment there > explicitely mentioning the behaviour. The behaviour predates ~ year > 2002, where extended attributes were introduced, and it makes sense. Thank-you for the pointer to the source. With the passage of 15 years other applications have come to use "system" namespace extended attributes, as though they were in the host system. Unfortunately if you have one physical box available to act as both an authentication server (Quasi Active Directory) and a fileserver, then using a jailed environment is the only solution. By design? I suppose its akin to saying, why would you want to use sysvipc from within a jail, with its global namespace (since FreeBSD V5.0) ; or perhaps the use of raw sockets (FreeBSDv6.0); or mount within a jail (FreeBSD V9.0); or...? Probably because sophisticated use of jails is one of the many outstanding features that sets FreeBSD apart from restrictive and antiquated environments. Not all features of a base system should be reflected in a jail, that would be silly; but where upstream applications use features, then the enhancement of a jail's configuration via way of, at least, an option - makes sense. Doesn't it? I suppose that the crux to the question is - why should the "system" namespace not be available within a jail? Aside: Someone on the SAMBA mailing list also using FreeBSD has a similar problem, but he's using bhyve - hence the use within the same sentence. Regards, Dewayne. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Extended "system" attributes within jailed environment dont work
On Fri, Jul 14, 2017 at 01:53:40PM +1000, Dewayne Geraghty wrote: > Can someone advise how I can enable extended attributes in a "system" > namespace within a jailed (or bhyve) environment? There was no guidance > in "man jail" nor "man jail.conf". Mentioning jails and bhyve in a single sentence clearly indicates serious issues with understanding either feature. > > Simple test > >From the host or base system: > # touch /a ; setextattr user t1 first /a ; getextattr user t1 /a > /a first > # touch /a ; setextattr system t2 second /a ; getextattr system t2 /a > /a second > > Within a jail: > # touch /a ; setextattr user t1 first /a ; getextattr user t1 /a > /a first > # touch /a ; setextattr system t2 second /a ; getextattr system t2 /a > setextattr: /a: failed: Operation not permitted > getextattr: /a: failed: Operation not permitted > > The impact of this is that SAMBA after 4.3 uses "system" namespace > extended attributes; hence can not provision an Active Directory within > a jailed environment. (For the inclined, this affects sysvol, and > interestingly "rsync -x" is unable to copy extended attributes, so > having consistent sysvols across a SAMBA domain may be a challenge) System namespace access is not allowed for jailed processes by design. See sys/kern/vfs_subr.c:extattr_check_cred() and a comment there explicitely mentioning the behaviour. The behaviour predates ~ year 2002, where extended attributes were introduced, and it makes sense. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Extended "system" attributes within jailed environment dont work
Can someone advise how I can enable extended attributes in a "system" namespace within a jailed (or bhyve) environment? There was no guidance in "man jail" nor "man jail.conf". Simple test >From the host or base system: # touch /a ; setextattr user t1 first /a ; getextattr user t1 /a /a first # touch /a ; setextattr system t2 second /a ; getextattr system t2 /a /a second Within a jail: # touch /a ; setextattr user t1 first /a ; getextattr user t1 /a /a first # touch /a ; setextattr system t2 second /a ; getextattr system t2 /a setextattr: /a: failed: Operation not permitted getextattr: /a: failed: Operation not permitted The impact of this is that SAMBA after 4.3 uses "system" namespace extended attributes; hence can not provision an Active Directory within a jailed environment. (For the inclined, this affects sysvol, and interestingly "rsync -x" is unable to copy extended attributes, so having consistent sysvols across a SAMBA domain may be a challenge) Regards, Dewayne. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
