Re: [RFC][PATCH] Remove security_inode_post_create/mkdir/symlink/mknod hooks

From: Stephen Smalley (sds@private)
Date: Mon Jul 18 2005 - 05:50:23 PDT


On Fri, 2005-07-15 at 13:00 -0700, John Johansen wrote:
> On Thu, Jul 14, 2005 at 03:29:37PM -0400, Stephen Smalley wrote:
> > This patch removes the inode_post_create/mkdir/mknod/symlink LSM hooks
> > as they are obsoleted by the new inode_init_security hook that enables
> > atomic inode security labeling.  If anyone sees any reason to retain these hooks,
> > please speak now.  Also, is anyone using the post_rename/link hooks; if not,
> > those could also be removed.
> > 
> The new inode_init_security hook doesn't receive the dentry information
> that the inode_post_create/mkdir/mknod/symlink LSM hooks receive.  This is a
> problem for subdomain because we rely on dentry information.

The entire point of inode_init_security is to allow security setup
_before_ the new inode is associated with a dentry (and thus accessible
via the dcache to other threads).  Otherwise, other threads can access
it before it is properly labeled.

Also, last I looked, SubDomain wasn't using any of the inode post hooks.
Got code?

> also the inode_init_security hook forces labeling through xattrs, where the
> inode_post_create/mkdir/mknod/symlink hooks all labeling through files, which
> allows for fallback support on filesystem that don't support xattrs.

No, it doesn't force labeling through xattrs.  It just provides a way to
perform security setup for new inodes (of the incore inode and
optionally of any on-disk xattr) prior to the inode becoming accessible
to other threads via the dcache.  Note that we also added the new hook
to tmpfs.  

If you aren't concerned about the lack of atomicity, you could just as
well use the d_instantiate hook.

-- 
Stephen Smalley
National Security Agency



This archive was generated by hypermail 2.1.3 : Mon Jul 18 2005 - 05:53:43 PDT