Konstantin Belousov
2017-Jul-14 07:56 UTC
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.
Dewayne Geraghty
2017-Jul-14 09:28 UTC
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.