On Wed, 2009-08-19 at 19:41 -0700, Eric W. Biederman wrote: > Casey Schaufler <casey@xxxxxxxxxxxxxxxx> writes: > > > So I still don't like the way it exposes LSM internal data to the > > file system code, but given how long it's taking for me to create > > a better solution I don't think that I can in all fairness say NAK > > to David Quigley's sysfs patch any longer. I withdraw my objection, > > while maintaining my reservations. > > Until I see it wired up against another filesystem I retain my > objections. When I asked he pretty much told me that it doesn't > generalize to other filesystems well and it is a sysfs special case. I think that's a misunderstanding (likely our fault). As I said, we already have what we need for getting and setting security xattrs on in-memory filesystems that pin their inodes, so the only missing bit was the ability to preserve userspace-set attributes in in-memory filesystems that can evict their inodes. And the hooks proposed by David are generic for that purpose. You still have to add them to each such in-memory filesystem that doesn't pin its inodes as each has its own distinct backing data structure, but you don't need more hooks or a different approach. > The way sysctl and proc are wired as special cases into the lsm > has been a maintenance disaster so far, and I think it a very bad > idea to add yet another lsm special case, that supports only one > filesystem. -- Stephen Smalley National Security Agency -- 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.
