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 -- 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
