Re: xattr names for unprivileged stacking?

[Andreas Dilger <adilger@dilger.ca>]

[-- Attachment #1: Type: text/plain, Size: 2287 bytes --]

On Aug 31, 2020, at 7:23 AM, Matthew Wilcox <willy@infradead.org> wrote:
> 
> On Mon, Aug 31, 2020 at 01:51:20PM +0200, Miklos Szeredi wrote:
>> On Mon, Aug 31, 2020 at 1:37 PM Matthew Wilcox <willy@infradead.org> wrote:
>> 
>>> As I said to Dave, you and I have a strong difference of opinion here.
>>> I think that what you are proposing is madness.  You're making it too
>>> flexible which comes with too much opportunity for abuse.
>> 
>> Such as?
> 
> One proposal I saw earlier in this thread was to do something like
> $ runalt /path/to/file ls
> which would open_alt() /path/to/file, fchdir to it and run ls inside it.
> That's just crazy.
> 
>>> I just want
>>> to see alternate data streams for the same filename in order to support
>>> existing use cases.  You seem to be able to want to create an entire
>>> new world inside a file, and that's just too confusing.
>> 
>> To whom?  I'm sure users of ancient systems with a flat directory
>> found directory trees very confusing.  Yet it turned out that the
>> hierarchical system beat the heck out of the flat one.
> 
> Which doesn't mean that multiple semi-hidden hierarchies are going to
> be better than one visible hierarchy.

I can see the use of ADS for "additional information" about a single file
(e.g. verity Merkle tree with checksums of the file data) that are too big
to put into an xattr and/or need random updates.  However, I don't see the
benefits of attaching a whole arbitrary set of files to a single filename.

If people want a whole hierarchy of directories contained within a single
file, why not use a container (e.g. ext4 filesystem image) to hold all of
that?  That allows an arbitrary group of files/directories/permissions to
be applied to a tree of files, but the container can be copied or removed
atomically as needed?

Using a filesystem image as the container is (IMHO) preferable to using a
tarball or similar, because it can be randomly updated after creation, and
already has all of the semantics needed.

The main thing that is needed is some mechanism that users can access that
decides whether access to the image is as a file, or if processed should
automount the image and descend into the contained namespace.

Cheers, Andreas






[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 873 bytes --]