On Tue, 2009-05-12 at 11:12 +1000, James Morris wrote: > On Mon, 11 May 2009, Joel Becker wrote: > > > > e.g. SELinux will need to perform some checks on the operation, then > > > calculate a new security context for the new file. > > > > Do I need to pass in preserve_security as well so SELinux knows > > what the ownership check determined? > > Not for SELinux -- its security attributes are orthogonal to DAC, and it > will perform its own checks on them. Is preserve_security supposed to also control the preservation of the SELinux security attribute (security.selinux extended attribute)? I'd expect that either we preserve all the security-relevant attributes or none of them. And if that is the case, then SELinux has to know about preserve_security in order to know what the security context of the new inode will be. Also, if you are going to automatically degrade reflink(2) behavior based on the owner_or_cap test, then you ought to allow the same to be true if the security module vetoes the attempt to preserve attributes. Either DAC or MAC logic may say that security attributes cannot be preserved. Your current logic will only allow graceful degradation in the DAC case, but the MAC case will remain a hard failure. > Other LSMs should operate similarly (there is also the CAP_CHOWN check > which the LSM may hook), although if not, the flag can be added later if > required. > > > - James -- 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
