Re: [RFC] The reflink(2) system call v4.

[Stephen Smalley <sds@tycho.nsa.gov>]

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