--- Stephen Smalley <sds@private> wrote: > On Mon, 2005-07-18 at 08:53 -0700, Casey Schaufler > wrote: > > That's correct. You still need to add to the > > file system code to support the system call > > interface. But really, the only hard problem > > is what to do in the case of a file system with > > an inflexible on disk format, and I've provided > > what I can (due to corporate IP policies) on > > addressing that issue. > > Patching every pseudo filesystem to add an xattr > security handler, only > to have that security xattr handler call into the > security module to get > and set the incore inode security label, as we've > already done for > devpts and tmpfs, will yield a lot of code > duplication that can be > avoided via a generic fallback in the VFS. Yes, if all you want to do is introduce a hack to fix your particular problem that is a pragmatic solution. If you want to do the community a service xattr support for the file systems you use is better. I have no problem with a special purpose hack, but it shouldn't be imposed on the general population when the "right" solution is perfectly obvious. > In that > case, there is no > storage of xattrs at all, so there is nothing to do > besides calling the > security module. Or whatever extended attribute you might want. That's my point, that xattrs are good for more than security policies (e.g. audit) and a special-for-security kludge is w r o n g. > For legacy filesystems (e.g. think vfat), > implementing native xattr > support is a pointless exercise, even aside from > compatibility issues. Sorry, but it's useful and been done. > You just want to map them to a single security > label, which we can do, > but you also want to export that to userspace via > the standard > interface, which means you need to either implement > a handler in each > such filesystem that again just calls into the > security module, or you > provide a fallback in the VFS. Use the documented and support interfaces for file system development. Somehow you seem to think that in general only security and in specific only SELinux will ever use xattrs. That's wrong. If you are using xattrs to your gain you ought to contribute back to them, rather than proposing a one-off so you don't have to. > > Do you store that label anywhere? If you're > > referencing from the inode, no matter how > > indirectly, you ought to be able to expose it > > as an xattr. Now, if you have two you may have > > a naming issue to address, but I'm sure you > > can deal with that easily enough. > > The label is mapped to a SID and stored in the > incore inode's security > structure. In which case the file system code has easy access to it. > So the security module can easily > get/set it, but the > filesystem code cannot do so directly - it has to go > through an LSM hook > (as we've done in devpts and tmpfs). Moving that up > into the VFS avoids > duplicating that handler code in each such pseudo > filesystem (and legacy > filesystem). Feldercarb. The existing file system mechanisms are completely sufficient if you store your data properly. Casey Schaufler casey@schaufler-ca.com ____________________________________________________ Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs
This archive was generated by hypermail 2.1.3 : Mon Jul 18 2005 - 10:44:18 PDT