Re: Streams support in Linux

[Jeremy Allison <jra@samba.org>]

On Mon, Aug 27, 2018 at 11:21:43AM -0700, Matthew Wilcox wrote:
> On Mon, Aug 27, 2018 at 10:05:31AM -0700, Jeremy Allison wrote:
> > I can't think of a *single* case where a stream adds more
> > utility than an EA used in the same case.
> > 
> > I don't want theoretical "well it would be nice if..",
> > I want clear "we couldn't have done it any other way"
> > kinds of things.
> 
> I started this thread with such an example.  The fs-verity patch proposed
> wants to store hundreds of megabytes of data associated with a particular
> file.  The current solution is to append it to the end of the data then
> magic to set i_size lower but not remove the data from the file like a
> truncate would.  Then more magic to read that data.
> It can't be stored in an xattr; xattrs are limited to 64k in size.
> And you have to read them / write them all-in-one-go; you can't read
> a little bit of them.  How would you solve the fs-verity problem with
> less magic?

OK, fair enough. I concede that is a use-case that would
be easier if Linux had streams.

But as Al just pointed out, this is a case of a poor design.
There are other ways of solving this problem without introducing
a feature that adds *known* security issues and causes headaches for
people attempting to secure systems (scanners for "hidden"
data areas etc.). The greatest users of streams in Windows
are the virus-writing fraternity. Let's not add features
for them please.

But you also said:

> There are, of course, other clients for file streams.  Samba is one,
> GNOME could use streams for various desktoppy things, and I'm certain
> other users would come out of the woodwork if we had them.

This is not a good justification (IMHO). You have one
case where streams would make things easier. Samba might
use them on Linux if there were there, but we'd always
have to keep our non-Linux stream emulation code around
and up to date for our other important system FreeBSD
(I'm considering Solaris dead now, plus we never implemented
Solaris native streams in all the time they were available,
due to their limited availability on all other platforms).

This is a case of adding a nasty feature that encourages bad
security design "just because" it might be useful for user
space that currently works fine without it.

EA's work OK for Gnome. I doubt they want to store
hundreds of megabytes of extra meta-data hidden inside
a file, and on the off chance they do they also have
to emulate this on non-Linux systems anyway (as does
Samba).

Apple gets away with requiring streams in MacOSX as
they don't care about interop with anything other than
themselves and Windows. We're not in that position.

All pain, no gain IMHO :-).