On Thu, 19 Sep 2002, Greg KH wrote:
> Yes, and explaining the fine points of inode_init() and
> inode_alloc_security() and why they are different, might be a bit tough.
>
> {sigh}, well if there's no other way (and I can't think of one right
> now), but I really don't like it...
I've attached two new patches that attempt to support the same
functionality without inserting hooks into filesystem-specific code.
These patches permit the security module to perform initialization
of the inode security state based on the superblock information, enabling
SELinux to initialize pipe, devpts, and shm inodes without relying on
inode_precondition to catch them on first use.
In the 2.5 patch, this is achieved simply by moving the initialization of
inode->i_sb before the call to inode_alloc_security, enabling the
inode_alloc_security hook function to perform the allocation and
initialization for such inodes. No new hooks required in 2.5.
In 2.4, the sb->s_op->alloc_inode changes have not yet been merged into
the base kernel, so the superblock information is not presently available
when inode_alloc_security is called. Hence, as an interim measure until
these changes are merged into 2.4, the attached 2.4 patch adds a separate
inode_init hook in new_inode() to permit the same initialization. The 2.4
patch changes new_inode() from a static inline function to an extern
function with an exported symbol for modules. This change is already in
2.5, and will presumably show up in 2.4 later when the ->alloc_inode
changes are merged.
I've been able to work around the lack of inode mode format information at
this point in processing within SELinux.
Any objections to these patches?
--
Stephen D. Smalley, NAI Labs
ssmalleyat_private
This archive was generated by hypermail 2b30 : Thu Sep 26 2002 - 09:03:44 PDT