Re: xattr names for unprivileged stacking?

[Christian Schoenebeck <qemu_oss@crudebyte.com>]

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.

[1] https://en.wikipedia.org/wiki/Fork_(file_system)

Best regards,
Christian Schoenebeck