On Tue, Feb 07, 2017 at 09:41:00PM -0500, Theodore Ts'o wrote: > On Tue, Feb 07, 2017 at 05:52:15PM +0800, Anand Jain wrote: > > > > Sure. Hope I could confirm it here, that is - if its ok to entirely use > > setfattr / getfattr to read and write fs/crypto policy. > > The controls on when it is legal to set a crypto policy on a file are > different than for a normal extended attribute. Furthermore, what is > stored on disk is a combination of the fscrypt policy --- which is a > fixed part of the userspace API --- and the some per-file > cryptoggraphic nonces which are generated by the kernel, and which is > subject to change in the future depending on the changes in the key > derivation algorithm, the cipher used, etc. > > For this reason using the standard xattr interface is **strongly** > frowned upon. Using setfattr / getfattr for something that *isn't* > the standard user extended attribute has been a mess, and is > considered a mistake that shouldn't be repeated. > > This is why I chose to use a separate ioctl instead of trying to > bastardize the setfattr / getfattr interface for something which is > fundamentally *not* about setting an extended attribute. > > There was discussion on linux-fsdevel a few months back where someone > else wanted to perpetrate a similar abuse of the the set/get extended > attribute interface, and other folks (I think it was Christoph and > Dave Chinner) who argued very strongly that it wsa a bad, Bad, BAD, > *BAD* idea. As one of 'those people', I think I'm well qualified to say that a fake xattr having side effects that doesn't behave in quite the same ways as regular xattrs is setting up other programs (the ones that listxattr all the attrs and getxattrs them) for all kinds of weird yuckiness. And by 'weird yuckiness' I mean "this one magic xattr returned EOPNOTSUPP and the whole backup program exploded". Now granted you can argue that we're just shifting that into an ioctl, but ioctls are already weird and yucky. :) --D > > Cheers, > > - Ted
