Re: xattr names for unprivileged stacking?

From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: Christian Schoenebeck <qemu_oss@crudebyte.com>
Cc: Greg Kurz <groug@kaod.org>,
	linux-fsdevel@vger.kernel.org, stefanha@redhat.com,
	mszeredi@redhat.com, vgoyal@redhat.com, gscrivan@redhat.com,
	dwalsh@redhat.com, chirantan@chromium.org
Subject: Re: xattr names for unprivileged stacking?
Date: Wed, 12 Aug 2020 12:18:19 +0100	[thread overview]
Message-ID: <20200812111819.GE2810@work-vm> (raw)
In-Reply-To: <2627251.EZXEZLLarb@silver>

* Christian Schoenebeck (qemu_oss@crudebyte.com) wrote:
> On Dienstag, 4. August 2020 13:28:01 CEST Dr. David Alan Gilbert wrote:
> > > Well, depends on how large you draw the scope here. For instance Samba has
> > > a bunch VFS modules which also uses and hence prohibits certain xattrs.
> > > For instance for supporting (NTFS) alternate data streams (a.k.a.
> > > resource forks) of Windows clients it uses user.DosStream.*:
> > > 
> > > https://www.samba.org/samba/docs/current/man-html/vfs_streams_xattr.8.html
> > > 
> > > as well as "user.DOSATTRIB".
> > > 
> > > And as macOS heavily relies on resource forks (i.e. macOS doesn't work
> > > without them), there are a bunch of xattr remappings in the dedicated
> > > Apple VFS module, like "aapl_*":
> > > 
> > > https://www.samba.org/samba/docs/current/man-html/vfs_fruit.8.html
> > > https://github.com/samba-team/samba/blob/master/source3/modules/vfs_fruit.
> > > c
> > 
> > Thanks;  what I've added to virtiofsd at the moment is a generic
> > remapping thing that lets me add any prefix and block/drop any xattr.
> 
> Right, makes absolutely sense to make it configurable. There are too many use 
> cases for xattrs, and the precise xattr names are often configurable as well, 
> like with the mentioned Samba VFS modules.
> 
> > The other samba-ism I found was mvxattr(1) which lets you rename xattr's
> > ona  directory tree; which is quite useful.
> 
> Haven't seen that before, interesting.
> 
> BTW, I have plans for adding support for file forks [1] (a.k.a. alternate 
> streams, a.k.a. resource forks) on Linux kernel side, so I will probably come 
> up with an RFC in couple weeks to see whether there would be acceptance for 
> that at all and if yes in which form.
> 
> That would open a similar problematic to virtiofsd on the long term, as file 
> forks have a namespace on their own.

Yeh I'm sure that'll need wiring into lots of things in weird ways!
I guess the main difference between an extended attribute and a
file-fork is that you can access the fork using an fd and it feels more
like a file?

Dave

> [1] https://en.wikipedia.org/wiki/Fork_(file_system)
> 
> Best regards,
> Christian Schoenebeck
> 
> 
-- 
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK