Re: xattr names for unprivileged stacking?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Aug 31, 2020 at 10:25:32AM -0400, Theodore Y. Ts'o wrote:
> On Mon, Aug 31, 2020 at 02:23:39PM +0100, Matthew Wilcox 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@xxxxxxxxxxxxx> 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.
> 
> As I've said before, malware authors would love that features.  Most
> system administrators won't.
> 
> Oh, one other question about ADS; if a file system supports reflink,
> what is supposed to happen when you reflink a file?  You have to
> consider all of the ADS's to be reflinked as well? 

Absolutely.

But, unlike your implication that this is -really complex and hard
to do-, it's actually relatively trivial to do with the XFS
implementation I mentioned as each ADS stream is a fully fledged
inode that can point to shared data extents. If you can do data
manipulation on a regular inode, you'll be able to do it on an ADS,
and that includes copying ADS streams via reflink.

Indeed, this actually makes the 'cp' utility able to support ADS
wihtout modification. i.e 'cp --reflink=always' will "copy" ADS data
automatically, without even needing to be aware they exist....

Such behaviour is almost certainly no harder to implement in XFS as
an atomic, recoverable operation than the "unlink removes all the
ADSs attached to the inode" requirement.....

> In some ways, this
> is good, because the overhead and complexity will probably cause most
> file system maintainers to throw up their had, say this is madness,
> and refuse to implement it.  :-)

I disagree: requiring reflink to actually "copy" ADS transparently
actually makes things easier for userspace support of ADS.  Thanks
for suggesting the idea, Ted. :)

Cheers,

Dave.
-- 
Dave Chinner
david@xxxxxxxxxxxxx



[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux