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. In that case, there is no storage of xattrs at all, so there is nothing to do besides calling the security module. For legacy filesystems (e.g. think vfat), implementing native xattr support is a pointless exercise, even aside from compatibility issues. 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. > 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. 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). -- Stephen Smalley National Security Agency
This archive was generated by hypermail 2.1.3 : Mon Jul 18 2005 - 09:08:24 PDT