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
This archive was generated by hypermail 2b30 : Mon Dec 30 2002 - 08:03:35 PST