Stephen Smalley wrote: > On Mon, 2009-08-17 at 20:55 -0700, Casey Schaufler wrote: > >> From: Casey Schaufler <casey@xxxxxxxxxxxxxxxx> >> >> Another approach to limited xattr support in sysfs. >> >> I tried to listen to the objections to a linked list representation >> and I think that I understand that there isn't really any interest >> in supporting xattrs for real, only for those maintained by LSMs. >> I also looked carefully into the claims that memory usage is >> critical and that the code I had before was duplicating effort. >> >> This version lets the surrounding code do as much of the work as >> possible. Unlike the initial proposal for sysfs xattrs, it does not >> introduce any new LSM hooks, it uses hooks that already exist. It >> does not support any attributes on its own, it only provides for >> the attribute advertised by security_inode_listsecurity(). It could >> easily be used by other filesystems to provide the same LSM xattr >> support. It could also be extended to do the list based support for >> arbitrary xattrs without too much effort. >> >> Probably the oddest bit is that the inode_getsecurity hooks need to >> check to see if they are getting called before the inode is instantiated >> and return -ENODATA in that event. It would be possible to do a >> filesystem specific check instead, but this way provides for generally >> correct behavior at small cost. >> >> This has been tested with Smack, but not SELinux. I think that >> SELinux will work correctly, but it could be that a labeling >> behavior that is different than the "usual" instantiation labeling >> is actually desired. That would be an easy change. >> >> As always, let me know if I missed something obvious or if there's a >> fatal flaw in the scheme. >> > > The point of the David's patch was to provide a way to save the security > xattr in the backing data structure for sysfs entries when an attribute > value is set from userspace so that the value can be preserved if the > inode is evicted from memory and later re-instantiated. AFAICS, your > patch completely misses the problem. How about we just go back to > David's patch? > Oh no, that would use too much memory! Either you care about the value the user set, in which case you want to save the value the user set, or you don't. If you do, you have to save that value, not an LSM's interpretation of that value. No secids. No new hooks. I'll have another go. Thank you for the clarification. -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.
