Re: Displaying streams as xattrs

[ronnie sahlberg <ronniesahlberg@gmail.com>]

On Fri, 26 May 2023 at 02:15, Jeremy Allison <jra@samba.org> wrote:
>
> On Thu, May 25, 2023 at 08:57:18PM +1000, ronnie sahlberg via samba-technical wrote:
> >On Wed, 24 May 2023 at 08:34, Jeremy Allison <jra@samba.org> wrote:
> >>
> >> ADS - "Just Say No !"
> >
> >I think that is a flawed argument.
> >It only really means that the virus scanners are broken. So we tell
> >the virus scanner folks to fix their software.
> >Viruses hide inside all sort of files and metadata.
> >There are viruses that hide inside JPEG files too and some of them
> >even gain privilege escalations through carefully corrupted JPEG
> >files.
> >We fix the bugs in the parser, we don't "drop support for JPEG files".
>
> What is the use-case for ADS on Linux ? And don't say "Windows
> compatibility" - stories about your mother's advice about
> jumping off a cliff have meaning here :-).
>
> Give me an actual *need* for ADS on Linux that can't
> be satified any other way before you start plumbing
> this horror into the internal VFS code.

I think it is too late to stop alternate data streams from entering
the kernel. They, or their equivalents, are already part of the
kernel.
This discussion is more about how to unify these things and provide an
abstracted api that is common across all filesystems than each
filesystem having a unique way to access them.
Filesystems that have protocol support for this is NTFS (ADS), CIFS
(ADS), NFS4 (named attributes) and HFS (forks). there could be more, I
have not checked.
These four are probably the four most common filesystems in use today
(ignoring FAT) across all platforms so support for this type of
feature is pretty much uniquous.

I think what we want to do is to have a discussion across maintainers
of all these filesystems and see if there is desire to work out a
common API and featureset and how that API would look.
How that API would work and what it would look like is a question
worthy to discuss.
Solaris surfaced this feature via openat() but that is just one of
many possible implementations. A separate userspace library that
provides universal access to these streams using something else would
work just as well. The discussion should be on how probe interest and
work together to create a unified abstraction common across all
filesystems. Then later work on what exactly the kernel API to access
this would look like.

For use cases? Something as trivial as storing an icon for use by
graphical file managers would be a huge quality of life improvement.
Even better if it would be compatible with how windows explorer stores
those same icons.