Hi Eric,
However, the issue which I was getting at is that encryption might just diverge from the standard xattr interface too much for it to be appropriate. For example you would not be able to use removexattr() to remove the encryption xattr. Nor would the "replace" semantics of setxattr() work. Nor would 'getfattr --dump' and 'setfattr --restore' work,
because the encryption xattrs would be included in the xattr dump but would not, in general, be possible to restore.
yeah. I wonder if this is something we could foresee to work in the long run for the encrypt attribute. (assuming there is no threat due to this).
Also, if the API requires a binary structure, then you kind of need a custom program to use it anyway, and in that situation an ioctl() is just as easy (if not easier) to use.
btrfs used string which is also in line with /proc/crypto. and a separate RO attribute for IV.
Anyway, if your intent is to change the fscrypt API, note that this almost certainly can't be done because people are already using it. It would however be technically possible to add a new API and deprecate the old one, if there was a strong reason that made it worthwhile. Right now I am not convinced that switching to an xattr interface is a good enough reason.
IMO attributes are fundamental of sharing file-info to the rest of the stake holders in the OS and that's a strong enough reason.
As for why fscrypt uses "SELinux attributes", it doesn't. The xattrs have a special name which does not collide with any public namespace.
Ok. Thanks. I am updated.
(Also note that I was not personally involved in the original design of the fscrypt API at all, so others may know more than me about the design decisions.)
Sure. Hope I could confirm it here, that is - if its ok to entirely use setfattr / getfattr to read and write fs/crypto policy. Thanks, Anand
Eric
