Extended "system" attributes within jailed environment dont work

[Konstantin Belousov]

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.