On Tue, 2009-05-12 at 11:28 -0700, Joel Becker wrote: > On Tue, May 12, 2009 at 02:04:53PM -0400, Stephen Smalley wrote: > > On Tue, 2009-05-12 at 11:03 -0700, Joel Becker wrote: > > > As an aside, do inodes ever have more than one security.* > > > attribute? It would appear that security_inode_init_security() just > > > returns one attribute, but what if I had a system running under SMACK > > > and then changed to SELinux? Would my (existing) inode then have > > > security.smack and security.selinux attributes? > > > > No, there would be no security.selinux attribute and the file would be > > treated as having a well-defined 'unlabeled' attribute by SELinux. Not > > something you have to worry about. > > Even if I've run rstorecon? Basically, I'm trying to understand > if, in the !preserve_security case, ocfs2 can just do "link up the > existing xattrs, then set whatever we got from > security_inode_init_security()", or if we have to go through and delete > all security.* attributes before installing the result of > security_inode_init_security(). Likely a better example would be file capabilities (security.capability), as you might be using those simultaneously with SELinux (security.selinux). security_inode_init_security() is only going to return security.selinux, as new files don't get any file capabilities assigned by default. I guess you would want to delete security.capability from the reflink if preserve_security==0. > > > > I'd rather have two hooks, one to allow the security module to override > > > > preserve_security and one to allow the security module to deny the > > > > operation altogether. The former hook only needs to be called if > > > > preserve_security is not already cleared by the DAC logic. The latter > > > > hook needs to know the final verdict on preserve_security in order to > > > > determine the right set of checks to apply, which isn't necessarily > > > > limited to only checking read access. > > > > > > Ok, is that two hooks or one hook with specific error returns? > > > I don't care, it's up to the LSM group. I just can't come up with a > > > good distinguishing set of names if its two hooks :-) > > > > I suppose you could coalesce them into a single hook ala: > > error = security_inode_reflink(old_dentry, dir, &preserve_security); > > if (error) > > return (error); > > What fits in with the LSM convention. That's more important > than one-hook-vs-two. I think that the above example fits with the LSM convention. -- 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
