Re: Possible issue with linux xattr support?

On Tue, Aug 29, 2023 at 03:02:58PM -0400, Shawn Webb wrote:
> On Tue, Aug 29, 2023 at 05:45:51PM +0300, Dmitry Chagin wrote:
> > On Tue, Aug 29, 2023 at 12:59:11PM +0200, Felix Palmen wrote:
> > > * Dmitry Chagin <dchagin@freebsd.org> [20230828 18:57]:
> > > > On Mon, Aug 28, 2023 at 08:03:33AM +0200, Felix Palmen wrote:
> > > > > * Cy Schubert <Cy.Schubert@cschubert.com> [20230827 16:59]:
> > > > > > 
> > > > > > If we are to break it to fix a problem, maybe a sysctl to enable/disable then?
> > > > > 
> > > > > IMHO depends on the exact nature of the problem. If it's confirmed that
> > > > > it (always and only) breaks for jailed processes, just disabling it for
> > > > > them would be the better workaround. "No-op" calls won't break anything.
> > > > > 
> > > > 
> > > > please, try: https://people.freebsd.org/~dchagin/xattrerror.patch
> > > 
> > > Thanks, I can confirm this avoids the issue in both cases I experienced
> > > (install from GNU coreutils and python).
> > > 
> > thanks, this is the first half of the fix, it works for you due to you
> > are running tools under unprivileged user, afaiu. The second I have
> > tested by myself :)
> > 
> > > If I understand this patch correctly, it completely avoids EPERM,
> > > masking it as not supported, so callers should consider it non-fatal,
> > > allowing to silently ignore writing of "system" attributes while still
> > > keeping other functionality?
> > > 
> > system namespace is accessible only for privileged user, for others Linux
> > returns ENOTSUP. So many tools ignores this error, eg ls.
> > 
> > the second: https://people.freebsd.org/~dchagin/sea_jailed.patch
> > 
> > Try this under privileged user, please.
> 
> Back in 2019, I had a similar issue: I needed access to be able to
> read/write to the system extended attribute namespace from within a
> jailed context. I wrote a rather simple patch that provides that
> support on a per-jail basis:
> 
> https://git.hardenedbsd.org/hardenedbsd/HardenedBSD/-/commit/96c85982b45e44a6105664c7068a92d0a61da2a3
> 
> Hopefully that's useful to someone.
> 

Nice, thank you. I'd prefer to disable it by default, like on a host.