Displaying streams as xattrs

[Jeremy Allison]

On Fri, May 26, 2023 at 12:39:34PM +1000, ronnie sahlberg wrote:
>On Fri, 26 May 2023 at 02:15, Jeremy Allison <jra at 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 at 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.

Where ? Yes, they're in NTFS/SMB1-2-3/HFS because they have to be
for compatibility with other systems.

I don't see any Linux native filesystem that has these
things.

Please do not add them.

>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.

As is the question of whether this should be done at all.

>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.

GNOME works perfectly well without alternate data streams.

I don't see adding them would be a quality of life improvement,
and an extra morass of complexity for developers.

ADS is the motherlode of bad ideas for filesystems.