Extended "system" attributes within jailed environment dont work

[Dewayne Geraghty]

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.