Re: [patch] Hook for d_instantiate

sdsat_private

Did anyone else have any comments on the addition of a d_instantiate hook or on 
the removal of the inode_post_lookup hook?  If not, I'd like to add this hook 
and remove inode_post_lookup from the lsm-2.4 and lsm-2.5 BitKeeper trees.

Of the other in-tree security modules, the only one that will be affected by the 
removal of inode_post_lookup is DTE.  I would expect that Serge would want to 
rework it to use the d_instantiate hook anyway given the problems with the 
inode_post_lookup hook that I mentioned previously, but I don't know how soon he 
is likely to be able to work on it.  I may be able to provide an initial cut at 
a d_instantiate hook for DTE, but can't really vouch for its correctness.  Side 
note:  DTE doesn't compile in the 2.5 tree at present due to the sys_security 
removal and header file issues.  I can fix the compilation problems, but 
deciding how to address the sys_security removal for DTE is naturally up to 
Serge. 

> The attached patch adds a hook for d_instantiate to the lsm-2.5 tree.  I also 
> have a patch for the 2.4 tree, but it is essentially the same other than the 
> extra diff in 2.5 for d_splice_alias.
> 
> The purpose of this hook is to provide security modules with a reliable means 
of 
> initializing the inode security structures before the inode becomes accessible 
> through the dcache.  The existing inode_post_lookup hook is inadequate in 
> several ways:
> 1) It is subject to races since the inode is already accessible through the 
> dcache before it is called,
> 2) It doesn't handle filesystems that directly populate the dcache,
> 3) It isn't always called in the desired context, e.g. for pipe, shm, and 
devpts 
> inodes, we want to perform this initialization in the context of the 
allocating 
> process after the inode's other state such as mode and uid have been set.
> 
> Note that the d_instantiate hook call is performed before attaching the inode 
> and before taking the dcache lock.  
> 
> A few caveats when implementing this hook:
> a) The 'inode' can be NULL.  Most (all?) modules will simply return 
immediately 
> in that case.  We could optionally only call the hook for non-NULL inodes.
> b) The inode is not attached yet when this hook is called.  Don't try to use 
> dentry->d_inode.  That's the point. You get to fill in the inode security
> state before it gets attached.

--
Stephen Smalley, NSA
sdsat_private

_______________________________________________
linux-security-module mailing list
linux-security-moduleat_private
http://mail.wirex.com/mailman/listinfo/linux-security-module