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

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

On Fri, 2009-05-15 at 09:25 +1000, James Morris wrote:
> On Thu, 14 May 2009, Stephen Smalley wrote:
> 
> > And you can likely make preserve_security a simple bool (set from some
> > caller-provided flag) rather than an int.  At which point the SELinux
> > wiring for the new hook would be something like this:
> > 
> > If we are preserving security attributes on the reflink, then treat it
> > like creating a link to an existing file;
> 
> Do we also need to somewhat consider it like a new file? e.g. in the case 
> of create_sid being set (if different to the existing security attribute), 
> I believe we need to fail the operation because security attributes are 
> not preserved, and also decide which error code to return (the user may be 
> confused if it's EACCES -- EINVAL might be better).  Similar for reflinks 
> on a context mounted file system, although create_sid needs to be checked 
> during inode instantiation (unless we, say, add set a preserve_sid flag 
> which overrides create_sid and is cleared upon use).

The create_sid is not relevant in the preserve_security==1 case; the
filesystem will always preserve the security context from the original
inode on the new inode in that case.  The create_sid won't ever be used
in that case, as it only gets applied if the filesystem calls
security_inode_init_security() to obtain the attribute (name, value)
pair for a new inode, and the filesystem will only do that in the
preserve_security==0 case.

-- 
Stephen Smalley
National Security Agency