On Wed, 2009-05-13 at 09:43 -0700, Joel Becker wrote: > On Tue, May 12, 2009 at 06:47:04PM -0700, Casey Schaufler wrote: > > Joel Becker wrote: > > > Oh, absolutely. > > > As an aside, do inodes ever have more than one security.* > > > attribute? > > > > ACLs, capability sets and Smack labels can all exist on a file at > > the same time. I know of at least one effort underway to create a > > multiple-label LSM. > > So ACLs and cap sets live under security.*? That's good. File capabilities live under security.*, but ACLs predate the security namespace and live in the system namespace as "system.posix_acl_access" (and if a directory, there is also a "system.posix_acl_default" attribute that specifies the default ACL for new files in that directory). In the preserve_security==0 case, you'd want to: - drop all attributes under security.* on the new inode, - set (security.<name>, value) to the name:value pair provided by security_inode_init_security(), - set system.posix_acl_access to the default ACL associated with the parent directory (the "system.posix_acl_default" attribute on the parent). The latter two steps are what is already done in the new inode creation code path, so you hopefully can just reuse that code. > > > Would my (existing) inode then have > > > security.smack and security.selinux attributes? > > > > > > > Yup. It happens all the time. Whenever someone converts a Fedora > > system to Smack they end up with a filesystem full of unused selinux > > labels. It does no harm. > > At that runtime, sure. But with reflink(), we may be reflinking > someone else's inode, and if we have to drop its security state, we > should clean the unused labels just in case they go back to selinux (or > back to smack, etc). But if they are all under security.*, it's easy to > do. > > Thanks! > Joel > -- Stephen Smalley National Security Agency -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
