Displaying streams as xattrs

Displaying streams as xattrs

[Steve French]

Looking through code today (in fs/cifs/xattr.c) I noticed an old
reference to returning alternate data streams as pseudo-xattrs.
Although it is possible to list streams via "smbinfo filestreaminfo"
presumably it is not common (opening streams on remote files from
Linux is probably not done as commonly as it should be as well).

Any thoughts about returning alternate data streams via pseudo-xattrs?
Macs apparently allow this (see e.g.
https://www.jankyrobotsecurity.com/2018/07/24/accessing-alternate-data-streams-from-a-mac/)





--
Thanks,

Steve

Re: Displaying streams as xattrs

[ronnie sahlberg]

A problem  we have with xattrs today is that we use EAs and these are
case insensitive.
Even worse I think windows may also convert the names to uppercase :-(
And there is no way to change it in the registry :-(

On Mon, 22 May 2023 at 12:09, Steve French via samba-technical
<samba-technical@lists.samba.org> wrote:
>
> Looking through code today (in fs/cifs/xattr.c) I noticed an old
> reference to returning alternate data streams as pseudo-xattrs.
> Although it is possible to list streams via "smbinfo filestreaminfo"
> presumably it is not common (opening streams on remote files from
> Linux is probably not done as commonly as it should be as well).
>
> Any thoughts about returning alternate data streams via pseudo-xattrs?
> Macs apparently allow this (see e.g.
> https://www.jankyrobotsecurity.com/2018/07/24/accessing-alternate-data-streams-from-a-mac/)
>
>
>
>
>
> --
> Thanks,
>
> Steve
>

Re: Displaying streams as xattrs

[Steve French]

On Sun, May 21, 2023 at 11:33 PM ronnie sahlberg
<ronniesahlberg@gmail.com> wrote:
>
> A problem  we have with xattrs today is that we use EAs and these are
> case insensitive.
> Even worse I think windows may also convert the names to uppercase :-(
> And there is no way to change it in the registry :-(

But for alternate data streams if we allowed them to be retrieved via xattrs,
would case sensitivity matter?  Alternate data streams IIRC are already
case preserving.   Presumably the more common case is for a Linux user
to read (or backup) an existing alternate data stream (which are usually
created by Windows so case sensitivity would not be relevant).

> On Mon, 22 May 2023 at 12:09, Steve French via samba-technical
> <samba-technical@lists.samba.org> wrote:
> >
> > Looking through code today (in fs/cifs/xattr.c) I noticed an old
> > reference to returning alternate data streams as pseudo-xattrs.
> > Although it is possible to list streams via "smbinfo filestreaminfo"
> > presumably it is not common (opening streams on remote files from
> > Linux is probably not done as commonly as it should be as well).
> >
> > Any thoughts about returning alternate data streams via pseudo-xattrs?
> > Macs apparently allow this (see e.g.
> > https://www.jankyrobotsecurity.com/2018/07/24/accessing-alternate-data-streams-from-a-mac/)
> >
> >
> >
> >
> >
> > --
> > Thanks,
> >
> > Steve
> >



-- 
Thanks,

Steve

Re: Displaying streams as xattrs

[ronnie sahlberg]

We want to expose ADS to the applications?
Maybe FCNTL is a better interface to do this than magix xattrs.
An application could open a file, and then use fcntl to
list/open/create/delete streams?

We should talk to the NTFS maintainers too as this is an ntfs feature
and they might alwo want to expose ADS to apps.
So we get a solution that we can use across multiple filesystems.

regards
ronnie s



On Mon, 22 May 2023 at 16:40, Steve French <smfrench@gmail.com> wrote:
>
> On Sun, May 21, 2023 at 11:33 PM ronnie sahlberg
> <ronniesahlberg@gmail.com> wrote:
> >
> > A problem  we have with xattrs today is that we use EAs and these are
> > case insensitive.
> > Even worse I think windows may also convert the names to uppercase :-(
> > And there is no way to change it in the registry :-(
>
> But for alternate data streams if we allowed them to be retrieved via xattrs,
> would case sensitivity matter?  Alternate data streams IIRC are already
> case preserving.   Presumably the more common case is for a Linux user
> to read (or backup) an existing alternate data stream (which are usually
> created by Windows so case sensitivity would not be relevant).
>
> > On Mon, 22 May 2023 at 12:09, Steve French via samba-technical
> > <samba-technical@lists.samba.org> wrote:
> > >
> > > Looking through code today (in fs/cifs/xattr.c) I noticed an old
> > > reference to returning alternate data streams as pseudo-xattrs.
> > > Although it is possible to list streams via "smbinfo filestreaminfo"
> > > presumably it is not common (opening streams on remote files from
> > > Linux is probably not done as commonly as it should be as well).
> > >
> > > Any thoughts about returning alternate data streams via pseudo-xattrs?
> > > Macs apparently allow this (see e.g.
> > > https://www.jankyrobotsecurity.com/2018/07/24/accessing-alternate-data-streams-from-a-mac/)
> > >
> > >
> > >
> > >
> > >
> > > --
> > > Thanks,
> > >
> > > Steve
> > >
>
>
>
> --
> Thanks,
>
> Steve

Re: Displaying streams as xattrs

[Jeremy Allison]

On Mon, May 22, 2023 at 01:39:50AM -0500, Steve French wrote:
>On Sun, May 21, 2023 at 11:33 PM ronnie sahlberg
><ronniesahlberg@gmail.com> wrote:
>>
>> A problem  we have with xattrs today is that we use EAs and these are
>> case insensitive.
>> Even worse I think windows may also convert the names to uppercase :-(
>> And there is no way to change it in the registry :-(
>
>But for alternate data streams if we allowed them to be retrieved via xattrs,
>would case sensitivity matter?  Alternate data streams IIRC are already
>case preserving.   Presumably the more common case is for a Linux user
>to read (or backup) an existing alternate data stream (which are usually
>created by Windows so case sensitivity would not be relevant).

Warning Will Robinson ! Mixing ADS and xattrs on the client side is a receipe for
confusion and disaster IMHO.

They really are different things. No good will come of trying to mix
the two into one client namespace.

Re: Displaying streams as xattrs

[ronnie sahlberg]

Yeah, I don't think we should surface these as xattrs.
Xattrs are already way too small for most of the usecases of ADS on
windows (file metadata for explorer etc)
and they are also just an atomic blob and not a proper filedescriptor.
Since ADS is still just a file, any application that in the future
will use ADS features should only do so via
a proper filedescriptors, where it is possible to
seek/read/write/truncate/...  so IMHO we shouldn't offer them an
alternative but inferior API. Because they might mistakenly start to use it. :-(

There are no real applications, yet, for linux that uses ADS but there
are many that potentially could use ADS or
become ADS aware. GUI Filebrowsers would be a nice usecase. As would
making 'cp', 'mv', 'tar', 'rsync', ... ADS aware.

So let's not do it with xattrs.
No one needs/asks for this right now so it would be code we will have
to maintain but has no users.


What we should do though is think about and talk with the NTFS folks
so that we make sure our aims and APIs will align with the plans they
have.
And once we have multiple filesystems supporting it (cifs.ko and ntfs)
then we can start thinking about how to encourage external users and
applications to use it.
There are really nice use-cases for ADS where one can store additional
metadata within the "file" itself.

regards
ronnie s

On Tue, 23 May 2023 at 02:21, Jeremy Allison <jra@samba.org> wrote:
>
> On Mon, May 22, 2023 at 01:39:50AM -0500, Steve French wrote:
> >On Sun, May 21, 2023 at 11:33 PM ronnie sahlberg
> ><ronniesahlberg@gmail.com> wrote:
> >>
> >> A problem  we have with xattrs today is that we use EAs and these are
> >> case insensitive.
> >> Even worse I think windows may also convert the names to uppercase :-(
> >> And there is no way to change it in the registry :-(
> >
> >But for alternate data streams if we allowed them to be retrieved via xattrs,
> >would case sensitivity matter?  Alternate data streams IIRC are already
> >case preserving.   Presumably the more common case is for a Linux user
> >to read (or backup) an existing alternate data stream (which are usually
> >created by Windows so case sensitivity would not be relevant).
>
> Warning Will Robinson ! Mixing ADS and xattrs on the client side is a receipe for
> confusion and disaster IMHO.
>
> They really are different things. No good will come of trying to mix
> the two into one client namespace.

Re: Displaying streams as xattrs

[Andrew Walker]

On Mon, May 22, 2023 at 8:00 PM ronnie sahlberg via samba-technical
<samba-technical@lists.samba.org> wrote:
>
> Yeah, I don't think we should surface these as xattrs.
> Xattrs are already way too small for most of the usecases of ADS on
> windows (file metadata for explorer etc)
> and they are also just an atomic blob and not a proper filedescriptor.
> Since ADS is still just a file, any application that in the future
> will use ADS features should only do so via
> a proper filedescriptors, where it is possible to
> seek/read/write/truncate/...  so IMHO we shouldn't offer them an
> alternative but inferior API. Because they might mistakenly start to use it. :-(
>
> There are no real applications, yet, for linux that uses ADS but there
> are many that potentially could use ADS or
> become ADS aware. GUI Filebrowsers would be a nice usecase. As would
> making 'cp', 'mv', 'tar', 'rsync', ... ADS aware.
>
> So let's not do it with xattrs.
> No one needs/asks for this right now so it would be code we will have
> to maintain but has no users.
>
>
> What we should do though is think about and talk with the NTFS folks
> so that we make sure our aims and APIs will align with the plans they
> have.
> And once we have multiple filesystems supporting it (cifs.ko and ntfs)
> then we can start thinking about how to encourage external users and
> applications to use it.
> There are really nice use-cases for ADS where one can store additional
> metadata within the "file" itself.
>
> regards
> ronnie s
>
> On Tue, 23 May 2023 at 02:21, Jeremy Allison <jra@samba.org> wrote:
> >
> > On Mon, May 22, 2023 at 01:39:50AM -0500, Steve French wrote:
> > >On Sun, May 21, 2023 at 11:33 PM ronnie sahlberg
> > ><ronniesahlberg@gmail.com> wrote:
> > >>
> > >> A problem  we have with xattrs today is that we use EAs and these are
> > >> case insensitive.
> > >> Even worse I think windows may also convert the names to uppercase :-(
> > >> And there is no way to change it in the registry :-(
> > >
> > >But for alternate data streams if we allowed them to be retrieved via xattrs,
> > >would case sensitivity matter?  Alternate data streams IIRC are already
> > >case preserving.   Presumably the more common case is for a Linux user
> > >to read (or backup) an existing alternate data stream (which are usually
> > >created by Windows so case sensitivity would not be relevant).
> >
> > Warning Will Robinson ! Mixing ADS and xattrs on the client side is a receipe for
> > confusion and disaster IMHO.
> >
> > They really are different things. No good will come of trying to mix
> > the two into one client namespace.
>

Solaris / Illumos had a neat feature where you could say openat(fd,
O_RDWR | O_XATTR) to open a stream on ZFS and then do normal file IO
to the stream (pread, pwrite, etc).

Re: Displaying streams as xattrs

[Jeremy Allison]

On Tue, May 23, 2023 at 10:59:27AM +1000, ronnie sahlberg wrote:

>There are really nice use-cases for ADS where one can store additional
>metadata within the "file" itself.

"Nice" for virus writers, yeah. A complete swamp for everyone
else :-).

Re: Displaying streams as xattrs

[ronnie sahlberg]

On Wed, 24 May 2023 at 02:25, Jeremy Allison <jra@samba.org> wrote:
>
> On Tue, May 23, 2023 at 10:59:27AM +1000, ronnie sahlberg wrote:
>
> >There are really nice use-cases for ADS where one can store additional
> >metadata within the "file" itself.
>
> "Nice" for virus writers, yeah. A complete swamp for everyone
> else :-).

Viruses? I don't think they use ADS much since most tools under
windows understand ADS.
ACE's on the other handd.
Which reminds me I need to write that tool to store/retrieve files
stored inside "hidden" entries in the security descriptor.

Re: Displaying streams as xattrs

[Jeremy Allison]

On Wed, May 24, 2023 at 07:44:36AM +1000, ronnie sahlberg wrote:
>On Wed, 24 May 2023 at 02:25, Jeremy Allison <jra@samba.org> wrote:
>>
>> On Tue, May 23, 2023 at 10:59:27AM +1000, ronnie sahlberg wrote:
>>
>> >There are really nice use-cases for ADS where one can store additional
>> >metadata within the "file" itself.
>>
>> "Nice" for virus writers, yeah. A complete swamp for everyone
>> else :-).
>
>Viruses? I don't think they use ADS much since most tools under
>windows understand ADS.

https://insights.sei.cmu.edu/blog/using-alternate-data-streams-in-the-collection-and-exfiltration-of-data/

"Malware that takes advantage of ADSs is not new. MITRE lists over a
dozen named malware examples that use ADSs to hide artifacts and evade
detection. Attack tools, such as Astaroth, Bitpaymer, and PowerDuke,
have been extensively detailed by various parties, providing insight
into how these threats take advantage of ADS evasion on a host system.
Authors, such as Berghel and Brajkovska, downplay the risks of ADSs. Our
opinion, however, is that ADSs introduced the host of concealment and
obfuscation techniques outlined above, but little has been done to
mitigate these worries since their publication in 2004."

As I also recall the published US "hacking toolset" also used
an ADS on the root directory of a share to exfiltrate data
from the target.

ADS - "Just Say No !"

:-).

Re: Displaying streams as xattrs

[ronnie sahlberg]

On Wed, 24 May 2023 at 08:34, Jeremy Allison <jra@samba.org> wrote:
>
> On Wed, May 24, 2023 at 07:44:36AM +1000, ronnie sahlberg wrote:
> >On Wed, 24 May 2023 at 02:25, Jeremy Allison <jra@samba.org> wrote:
> >>
> >> On Tue, May 23, 2023 at 10:59:27AM +1000, ronnie sahlberg wrote:
> >>
> >> >There are really nice use-cases for ADS where one can store additional
> >> >metadata within the "file" itself.
> >>
> >> "Nice" for virus writers, yeah. A complete swamp for everyone
> >> else :-).
> >
> >Viruses? I don't think they use ADS much since most tools under
> >windows understand ADS.
>
> https://insights.sei.cmu.edu/blog/using-alternate-data-streams-in-the-collection-and-exfiltration-of-data/
>
> "Malware that takes advantage of ADSs is not new. MITRE lists over a
> dozen named malware examples that use ADSs to hide artifacts and evade
> detection. Attack tools, such as Astaroth, Bitpaymer, and PowerDuke,
> have been extensively detailed by various parties, providing insight
> into how these threats take advantage of ADS evasion on a host system.
> Authors, such as Berghel and Brajkovska, downplay the risks of ADSs. Our
> opinion, however, is that ADSs introduced the host of concealment and
> obfuscation techniques outlined above, but little has been done to
> mitigate these worries since their publication in 2004."
>
> As I also recall the published US "hacking toolset" also used
> an ADS on the root directory of a share to exfiltrate data
> from the target.
>
> 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".

ronnie s

>
> :-).

Re: Displaying streams as xattrs

[Jeremy Allison]

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.

Re: Displaying streams as xattrs

[ronnie sahlberg]

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.

Re: 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@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.

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.

Re: Displaying streams as xattrs

[Björn JACKE]

On 2023-05-22 at 09:21 -0700 Jeremy Allison via samba-technical sent off:
> On Mon, May 22, 2023 at 01:39:50AM -0500, Steve French wrote:
> > On Sun, May 21, 2023 at 11:33 PM ronnie sahlberg
> > <ronniesahlberg@gmail.com> wrote:
> > > 
> > > A problem  we have with xattrs today is that we use EAs and these are
> > > case insensitive.
> > > Even worse I think windows may also convert the names to uppercase :-(
> > > And there is no way to change it in the registry :-(
> > 
> > But for alternate data streams if we allowed them to be retrieved via xattrs,
> > would case sensitivity matter?  Alternate data streams IIRC are already
> > case preserving.   Presumably the more common case is for a Linux user
> > to read (or backup) an existing alternate data stream (which are usually
> > created by Windows so case sensitivity would not be relevant).
> 
> Warning Will Robinson ! Mixing ADS and xattrs on the client side is a receipe for
> confusion and disaster IMHO.
> 
> They really are different things. No good will come of trying to mix
> the two into one client namespace.
> 

just took a look at how the ntfs-3g module is handling this. It was an option
streams_interface=value, which allows "windows", which means that the
alternative data streams are accessable as-is like in Windows, with ":" being
the separator. This might be a nice option for cifsfs also. That option would
just be usable if no posix extensions are enabled of course.

Björn

Re: Displaying streams as xattrs

[ronnie sahlberg]

On Thu, 25 May 2023 at 19:40, Björn JACKE via samba-technical
<samba-technical@lists.samba.org> wrote:
>
> On 2023-05-22 at 09:21 -0700 Jeremy Allison via samba-technical sent off:
> > On Mon, May 22, 2023 at 01:39:50AM -0500, Steve French wrote:
> > > On Sun, May 21, 2023 at 11:33 PM ronnie sahlberg
> > > <ronniesahlberg@gmail.com> wrote:
> > > >
> > > > A problem  we have with xattrs today is that we use EAs and these are
> > > > case insensitive.
> > > > Even worse I think windows may also convert the names to uppercase :-(
> > > > And there is no way to change it in the registry :-(
> > >
> > > But for alternate data streams if we allowed them to be retrieved via xattrs,
> > > would case sensitivity matter?  Alternate data streams IIRC are already
> > > case preserving.   Presumably the more common case is for a Linux user
> > > to read (or backup) an existing alternate data stream (which are usually
> > > created by Windows so case sensitivity would not be relevant).
> >
> > Warning Will Robinson ! Mixing ADS and xattrs on the client side is a receipe for
> > confusion and disaster IMHO.
> >
> > They really are different things. No good will come of trying to mix
> > the two into one client namespace.
> >
>
> just took a look at how the ntfs-3g module is handling this. It was an option
> streams_interface=value, which allows "windows", which means that the
> alternative data streams are accessable as-is like in Windows, with ":" being
> the separator. This might be a nice option for cifsfs also. That option would
> just be usable if no posix extensions are enabled of course.

We could. But that is a windowism where ':' is a reserved character
but which is not a reserved character in unixens.
For example:
You have the file "foo" with stream "bar" and you have another normal
file "foo:bar"
Which one does open("foo:bar") give you?

The openat/... semantics that solaris uses provides an elegant and
unambiguous semantics for it.
You want to open stream bar on file foo?
1, fh = open("foo")
2, sh = openatf(h, "bar")

There are at least two non-windows related filesystems that support
something similar to ADS,
solaris filesystem and apples filesystem(s) so it would be nice to
have a neutral API where an application can use the same
code to access streams be they cifs/ntfs/solarisfs/applefs/...other...

Steve, I think this would be a good discussion topic for vfs meetings.
Is it desirable to bless an api in the vfs to do alternate data
streams?
There are at least 4 filesystems that provide this feature, 3 of which
are still very popular and common today.

One approach would be to mimic the interface that solaris provides
with openatfile-fd, "stream-name")
But that would not just be a filesystem change but also a VFS change
since it would suddenly accept passing a file-fd as argument
as a valid option (for those filesystems that have signalled
alternative stream support?)
while the vfs currently only allows openat() on a directory-fd.

ADS as a concept is really powerful and could be enormously useful as
way to attach metadata to a file object in a standardized way.
There are very many use-cases where having a file that embedded both
the executable as well as various other types of data but still be
able to treat it as a single self-contained file from an end-user
perspective.

This should be discussed and we should probe the vfs folks about what
they think about it.

regards
ronnie s

>
> Björn
>

Re: Displaying streams as xattrs

[Jeremy Allison]

On Thu, May 25, 2023 at 08:49:47PM +1000, ronnie sahlberg wrote:
>>
>> just took a look at how the ntfs-3g module is handling this. It was an option
>> streams_interface=value, which allows "windows", which means that the
>> alternative data streams are accessable as-is like in Windows, with ":" being
>> the separator. This might be a nice option for cifsfs also. That option would
>> just be usable if no posix extensions are enabled of course.
>
>We could. But that is a windowism where ':' is a reserved character
>but which is not a reserved character in unixens.
>For example:
>You have the file "foo" with stream "bar" and you have another normal
>file "foo:bar"
>Which one does open("foo:bar") give you?
>
>The openat/... semantics that solaris uses provides an elegant and
>unambiguous semantics for it.
>You want to open stream bar on file foo?
>1, fh = open("foo")
>2, sh = openatf(h, "bar")
>
>There are at least two non-windows related filesystems that support
>something similar to ADS,
>solaris filesystem and apples filesystem(s) so it would be nice to
>have a neutral API where an application can use the same
>code to access streams be they cifs/ntfs/solarisfs/applefs/...other...
>
>Steve, I think this would be a good discussion topic for vfs meetings.
>Is it desirable to bless an api in the vfs to do alternate data
>streams?
>There are at least 4 filesystems that provide this feature, 3 of which
>are still very popular and common today.
>
>One approach would be to mimic the interface that solaris provides
>with openatfile-fd, "stream-name")

Solaris is dead, dead, dead. We should not resurrect the
warts of that thing in Linux.

>But that would not just be a filesystem change but also a VFS change
>since it would suddenly accept passing a file-fd as argument
>as a valid option (for those filesystems that have signalled
>alternative stream support?)
>while the vfs currently only allows openat() on a directory-fd.

I never thought I'd be calling on Christolph Hellwig
to squash such a horror before it emerges, but I'm
  CC:ing him on this email in the hope that he will :-).

>ADS as a concept is really powerful and could be enormously useful as
>way to attach metadata to a file object in a standardized way.
>There are very many use-cases where having a file that embedded both
>the executable as well as various other types of data but still be
>able to treat it as a single self-contained file from an end-user
>perspective.

Please give real examples of something for which this
is *essential*. Not "could be.. useful".

Hard mode. Windows has yet to find such an example :-).

One more datapoint: "still be able to treat it as a single self-contained
file from an end-user perspective." - please enumerate
every single tool and archiving program that will need
to be changed to treat a file containing alternate data
streams as "a single self-contained file".

>This should be discussed and we should probe the vfs folks about what
>they think about it.

I hope they just say no :-).

Re: Displaying streams as xattrs

[Steve French]

On Thu, May 25, 2023 at 11:22 AM Jeremy Allison <jra@samba.org> wrote:
>
> On Thu, May 25, 2023 at 08:49:47PM +1000, ronnie sahlberg wrote:
> >>
> >> just took a look at how the ntfs-3g module is handling this. It was an option
> >> streams_interface=value, which allows "windows", which means that the
> >> alternative data streams are accessable as-is like in Windows, with ":" being
> >> the separator. This might be a nice option for cifsfs also. That option would
> >> just be usable if no posix extensions are enabled of course.

You can already open alternate data streams remotely (from cifs.ko on Linux
as you can from Windows and Macs etc. just open "file:streamname"), but on
Linux you have to disable the reserved character mapping ("nomapposix")
otherwise ":" would get remapped on open in the Unicode conversion.

There may be a better way to list streams in the future (e.g. to help
backup applications
that need to be able to save files created by Macs or Windows that need these
e.g. Virus checkers etc. use ADS, and looking at my Windows machines, PDFs
can have small "Zone Identifiers" saved in streams), but you can
already list them
with "smbinfo filestreaminfo <filename>"

I was thinking mainly about backup scenarios whether this came up as
listing them
also via a pseudo-xattr (IIRC Macs do something similar).



-- 
Thanks,

Steve

Re: Displaying streams as xattrs

[Jeremy Allison]

On Thu, May 25, 2023 at 03:11:13PM -0500, Steve French wrote:
>On Thu, May 25, 2023 at 11:22 AM Jeremy Allison <jra@samba.org> wrote:
>>
>> On Thu, May 25, 2023 at 08:49:47PM +1000, ronnie sahlberg wrote:
>> >>
>> >> just took a look at how the ntfs-3g module is handling this. It was an option
>> >> streams_interface=value, which allows "windows", which means that the
>> >> alternative data streams are accessable as-is like in Windows, with ":" being
>> >> the separator. This might be a nice option for cifsfs also. That option would
>> >> just be usable if no posix extensions are enabled of course.
>
>You can already open alternate data streams remotely (from cifs.ko on Linux
>as you can from Windows and Macs etc. just open "file:streamname"), but on
>Linux you have to disable the reserved character mapping ("nomapposix")
>otherwise ":" would get remapped on open in the Unicode conversion.
>
>There may be a better way to list streams in the future (e.g. to help
>backup applications
>that need to be able to save files created by Macs or Windows that need these
>e.g. Virus checkers etc. use ADS, and looking at my Windows machines, PDFs
>can have small "Zone Identifiers" saved in streams), but you can
>already list them
>with "smbinfo filestreaminfo <filename>"
>
>I was thinking mainly about backup scenarios whether this came up as
>listing them
>also via a pseudo-xattr (IIRC Macs do something similar).

I think cifsfs providing access to ADS remotely on Windows
and Samba shares is fine.

What I'm scared of is adding ADS as a generic "feature" to
the Linux VFS and other filesystems :-).

Re: Displaying streams as xattrs

[Björn JACKE]

On 2023-05-25 at 13:22 -0700 Jeremy Allison sent off:
> I think cifsfs providing access to ADS remotely on Windows
> and Samba shares is fine.
> 
> What I'm scared of is adding ADS as a generic "feature" to
> the Linux VFS and other filesystems :-).

full ack on Jeremy's view here.

If there is something the the Linux VFS layer should *really* add to help 
interopearbility with basically all other major OS implementations is NFSv4
ACLs.  Seriously, for so many people living with Linux is a real pain due to
the lack of NFS4 ACLs here.

Björn
> 

Re: Displaying streams as xattrs

[Steve French]

On Thu, May 25, 2023 at 5:14 PM Björn JACKE <bj@sernet.de> wrote:
>
> On 2023-05-25 at 13:22 -0700 Jeremy Allison sent off:
> > I think cifsfs providing access to ADS remotely on Windows
> > and Samba shares is fine.
> >
> > What I'm scared of is adding ADS as a generic "feature" to
> > the Linux VFS and other filesystems :-).
>
> full ack on Jeremy's view here.
>
> If there is something the the Linux VFS layer should *really* add to help
> interoperability with basically all other major OS implementations is NFSv4
> ACLs.  Seriously, for so many people living with Linux is a real pain due to
> the lack of NFS4 ACLs here.

Today the "RichACLs" can be displayed multiple ways (e.g. "getcifsacl"
and various other
tools and also via system xattrs).
Being able to display "RichACLs" makes sense - and I am fine with
mapping these (and
probably would make sense to at least have a readonly mapping of the
existing richacls on
a file to "posixacl") and RichACLs are very important.

Wouldn't it be easier to let them also be queried for cifs.ko via
"system.getrichacl" (or whatever
the "getrichacl" tool used in various xfstests uses)?

I was also wondering how we should display (and how to retrieve via
SMB3) "claims based ACLs" (presumably these are reasonably common on a
few server types like Windows)?



-- 
Thanks,

Steve

Re: Displaying streams as xattrs

[ronnie sahlberg]

On Fri, 26 May 2023 at 09:50, Steve French <smfrench@gmail.com> wrote:
>
> On Thu, May 25, 2023 at 5:14 PM Björn JACKE <bj@sernet.de> wrote:
> >
> > On 2023-05-25 at 13:22 -0700 Jeremy Allison sent off:
> > > I think cifsfs providing access to ADS remotely on Windows
> > > and Samba shares is fine.
> > >
> > > What I'm scared of is adding ADS as a generic "feature" to
> > > the Linux VFS and other filesystems :-).
> >
> > full ack on Jeremy's view here.
> >
> > If there is something the the Linux VFS layer should *really* add to help
> > interoperability with basically all other major OS implementations is NFSv4
> > ACLs.  Seriously, for so many people living with Linux is a real pain due to
> > the lack of NFS4 ACLs here.
>
> Today the "RichACLs" can be displayed multiple ways (e.g. "getcifsacl"
> and various other
> tools and also via system xattrs).
> Being able to display "RichACLs" makes sense - and I am fine with
> mapping these (and
> probably would make sense to at least have a readonly mapping of the
> existing richacls on
> a file to "posixacl") and RichACLs are very important.
>
> Wouldn't it be easier to let them also be queried for cifs.ko via
> "system.getrichacl" (or whatever
> the "getrichacl" tool used in various xfstests uses)?

Lets not use xattrs for this.
Xattrs are capped at a very tiny maximum size for the amount of data
they can store
and I suspect very complex ACLs could probably quite easily grow
beyond that limit.


>
> I was also wondering how we should display (and how to retrieve via
> SMB3) "claims based ACLs" (presumably these are reasonably common on a
> few server types like Windows)?
>
>
>
> --
> Thanks,
>
> Steve

Re: Displaying streams as xattrs

[Björn JACKE]

On 2023-05-25 at 18:50 -0500 Steve French via samba-technical sent off:
> Today the "RichACLs" can be displayed multiple ways (e.g. "getcifsacl"
> and various other
> tools and also via system xattrs).
> Being able to display "RichACLs" makes sense - and I am fine with
> mapping these (and
> probably would make sense to at least have a readonly mapping of the
> existing richacls on
> a file to "posixacl") and RichACLs are very important.
> 
> Wouldn't it be easier to let them also be queried for cifs.ko via
> "system.getrichacl" (or whatever
> the "getrichacl" tool used in various xfstests uses)?
> 
> I was also wondering how we should display (and how to retrieve via
> SMB3) "claims based ACLs" (presumably these are reasonably common on a
> few server types like Windows)?

let's stop calling them RichACLs becuase that was only the name that Andreas
Grünbacher was giving his implementation of the NFS4 ACLs, which however never
mede it upstream to the kernel. Andreas is no longer interested in working on
those actually because because of a long lack of interest by the Kernel
maintainers back in those days. In any case, NFS4 ACLs are the right name, even
if the SMB people don't like the "NFS" in the name.

We have a summary of the state of NFS4 ACLs here:
https://wiki.samba.org/index.php/NFS4_ACL_overview . I recommend taking a
closer look at this.

If cifs.ko would add a mapping of SMB ACLs to the corresponding system.nfs4_acl
EA, this would be nice already but It will only be a limited help if cifs.ko.

The NFS4 ACL model needs to be supported by the Linux kernel also to be really
helpful. The nfs4-acl-tools are there to manage NFS4 ACLs already. To become
really helpful for Linux NFS4 ACLs need to be managable natively and also be
supported with generic filesystems and tools.

I've seen people who abandon to use Linux as client machines because of the
lack of ACL managability. Have in mind that the so called POSIX ACLs are not a
standardized permission model. The POSIX ACLs never passed the status of a
draft standard and the only standardized ACL permission model are in fact the
NFS4 ACLs. One of the main reason why FreeNAS or TrueNAS these days are based
on FreeBSD is the lack of NFS4 ACLs also.

I really wonder why the responsible people in the Kernel developer community
ignore this important topic since so many years. Would be nice to see them join
this thread ...

Björn

Re: Displaying streams as xattrs

[Steve French]

On Fri, May 26, 2023 at 7:54 PM Steve French <smfrench@gmail.com> wrote:
>
>
>
> On Fri, May 26, 2023, 06:03 Björn JACKE <bj@sernet.de> wrote:
>>
>> On 2023-05-25 at 18:50 -0500 Steve French via samba-technical sent off:
>> > Today the "RichACLs" can be displayed multiple ways (e.g. "getcifsacl"
>> > and various other
>> > tools and also via system xattrs).
>> > Being able to display "RichACLs" makes sense - and I am fine with
>> > mapping these (and
>> > probably would make sense to at least have a readonly mapping of the
>> > existing richacls on
>> > a file to "posixacl") and RichACLs are very important.
>> >
>> > Wouldn't it be easier to let them also be queried for cifs.ko via
>> > "system.getrichacl" (or whatever
>> > the "getrichacl" tool used in various xfstests uses)?
>> >
>> > I was also wondering how we should display (and how to retrieve via
>> > SMB3) "claims based ACLs" (presumably these are reasonably common on a
>> > few server types like Windows)?
>>
>> let's stop calling them RichACLs becuase that was only the name that Andreas
>> Grünbacher was giving his implementation of the NFS4 ACLs

The name "richacls" looks like it is embedded in the standard
filesystem functional tests
(to pass xfstests generic/362 through generic/370 requires this - so I
would have to finish
off the mapping of this richacl pseudo-xattr query to the SMB3.1.1 get
acl query over the wire).
It doesn't look too bad, and it would.   Most users would probably use
the normal
tools (like getcifsacl or even Samba's "smbcacls" user space tool or
the pseudo-xattr
e.g. system.cifs_ntsd_full) but if it helps to use a common format
that helps ntfs and nfsv4.1 and later
that is fine with me.


> Remember that at Connectathon conferences years ago when nfs4.1 ACLS were explained  (fixing NFS 4 ACLS to address some missed things). The NFS ACL ideas were modelled after smb ACLs so NFS ACLs have many similarities to their predecessor SMB ACLs (although presumably do not support claims based ACEs/CBAC/DAC yet)



-- 
Thanks,

Steve

Re: Displaying streams as xattrs

[Michael Weiser]

Hello Bjoern,

thanks for raising this point!

> If there is something the the Linux VFS layer should *really* add to help
> interopearbility with basically all other major OS implementations is NFSv4
> ACLs.  Seriously, for so many people living with Linux is a real pain due to
> the lack of NFS4 ACLs here.
[...]
> The NFS4 ACL model needs to be supported by the Linux kernel also to be really
> helpful. The nfs4-acl-tools are there to manage NFS4 ACLs already. To become
> really helpful for Linux NFS4 ACLs need to be managable natively and also be
> supported with generic filesystems and tools.

> I've seen people who abandon to use Linux as client machines because of the
> lack of ACL managability. Have in mind that the so called POSIX ACLs are not a

FWIW: I can second that: Many of our clients (as in customers) run (for
example) Linux HPC cluster headnodes with directly attached storage. For them,
exporting a local filesystem like ext4 or XFS via NFS *and* SMB is an important
use-case.

They don't have the time and expertise to dive into VFS modules and quirks of
NFSv4-to-POSIX-ACL mappings. So they actually limit themselves to just
standard permission bits and write cron jobs to regularly reset permissions.
Even if we manage to come up with a working setup for them, it's going to be
fragile in multiple dimensions. It's a pain.

Having consistent and powerful ACL support and enforcement across all access
paths (remote shell, NFS, SMB) that just works would be a huge leap forward for
them. Having cp -a retain the ACLs and their effects during copy from NFS mount
to local /tmp and back to an SMB mount would be a dream come true.
--
Thanks,
Michael
________________________________________
From: samba-technical <samba-technical-bounces@lists.samba.org> on behalf of Björn JACKE via samba-technical <samba-technical@lists.samba.org>
Sent: 26 May 2023 18:03:20
To: Steve French
Cc: CIFS; samba-technical; Jeremy Allison; Christoph Hellwig
Subject: Re: Displaying streams as xattrs

Caution: External email. Do not open attachments or click links, unless this email comes from a known sender and you know the content is safe.


On 2023-05-25 at 18:50 -0500 Steve French via samba-technical sent off:
> Today the "RichACLs" can be displayed multiple ways (e.g. "getcifsacl"
> and various other
> tools and also via system xattrs).
> Being able to display "RichACLs" makes sense - and I am fine with
> mapping these (and
> probably would make sense to at least have a readonly mapping of the
> existing richacls on
> a file to "posixacl") and RichACLs are very important.
>
> Wouldn't it be easier to let them also be queried for cifs.ko via
> "system.getrichacl" (or whatever
> the "getrichacl" tool used in various xfstests uses)?
>
> I was also wondering how we should display (and how to retrieve via
> SMB3) "claims based ACLs" (presumably these are reasonably common on a
> few server types like Windows)?

let's stop calling them RichACLs becuase that was only the name that Andreas
Grünbacher was giving his implementation of the NFS4 ACLs, which however never
mede it upstream to the kernel. Andreas is no longer interested in working on
those actually because because of a long lack of interest by the Kernel
maintainers back in those days. In any case, NFS4 ACLs are the right name, even
if the SMB people don't like the "NFS" in the name.

We have a summary of the state of NFS4 ACLs here:
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.samba.org%2Findex.php%2FNFS4_ACL_overview&data=05%7C01%7Cmichael.weiser%40atos.net%7C359c5b89a4aa453c20c108db5e02cb6a%7C33440fc6b7c7412cbb730e70b0198d5a%7C0%7C0%7C638207138314989061%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=96X1GeVCoPYo1s3wmxtiDMdnXkR%2Bn%2Bw%2BcVfILLB3HGo%3D&reserved=0 . I recommend taking a
closer look at this.

If cifs.ko would add a mapping of SMB ACLs to the corresponding system.nfs4_acl
EA, this would be nice already but It will only be a limited help if cifs.ko.

The NFS4 ACL model needs to be supported by the Linux kernel also to be really
helpful. The nfs4-acl-tools are there to manage NFS4 ACLs already. To become
really helpful for Linux NFS4 ACLs need to be managable natively and also be
supported with generic filesystems and tools.

I've seen people who abandon to use Linux as client machines because of the
lack of ACL managability. Have in mind that the so called POSIX ACLs are not a
standardized permission model. The POSIX ACLs never passed the status of a
draft standard and the only standardized ACL permission model are in fact the
NFS4 ACLs. One of the main reason why FreeNAS or TrueNAS these days are based
on FreeBSD is the lack of NFS4 ACLs also.

I really wonder why the responsible people in the Kernel developer community
ignore this important topic since so many years. Would be nice to see them join
this thread ...

Björn

Re: Displaying streams as xattrs

[Andrew Walker]

On Sun, May 21, 2023 at 9:08 PM Steve French <smfrench@gmail.com> wrote:
>
> Looking through code today (in fs/cifs/xattr.c) I noticed an old
> reference to returning alternate data streams as pseudo-xattrs.
> Although it is possible to list streams via "smbinfo filestreaminfo"
> presumably it is not common (opening streams on remote files from
> Linux is probably not done as commonly as it should be as well).
>
> Any thoughts about returning alternate data streams via pseudo-xattrs?
> Macs apparently allow this (see e.g.
> https://www.jankyrobotsecurity.com/2018/07/24/accessing-alternate-data-streams-from-a-mac/)
>
>
>
>
>
> --
> Thanks,
>
> Steve

Another issue with exposing ADS as xattr on Linux is that VFS caps max
xattr size at 64 KiB. I've seen MacOS resource forks in the wild with
sizes of up to 3 MiB. FCNTL sounds interesting.

Andrew