Re: [patch] inode_init hook

gregat_private

On Thu, Sep 19, 2002 at 08:20:55AM -0400, Stephen Smalley wrote:
> 
> On Wed, 18 Sep 2002, Greg KH wrote:
> 
> > Does this mean that hooks like these are going to have to be added to
> > every filesystem that does their own inode initialization, like devpts?
> > Now that some developers {cough, cough} understand the vfs better, some
> > of the in-kernel filesystems are starting to go around the vfs to solve
> > real problems.  Will they also need to be modified like this?  (as an
> > example, look at how usbfs and driverfs have changed over the past few
> > months...)
> >
> > Hm, in looking at this further, why doesn't the hook in alloc_inode()
> > catch these instances?  It is called right before you are wanting
> > inode_init() to be called.
> 
> When inode_alloc_security is called, no information about the inode is
> available, so we cannot determine its security information.  It can only
> allocate the inode security blob, not perform the actual initialization
> of the security information.  Notice that we already have separate
> initialization hooks for other kinds of inodes, e.g. inode_post_lookup for
> file inodes and socket_post_create/accept for socket inodes.
> 
> I'd certainly like to have the inode_init hook in a single central
> location, but SELinux needs the inode mode to be set in the inode prior to
> the hook call or passed in as a parameter to the hook call so that we can
> use it in determining the security class and the SID of the inode.  The
> multiple hook calls in the patch parallel the existing kernel code for
> setting the other "security" attributes in the inode (e.g. the uid and
> gid), so the patch is consistent with the existing kernel code, but it
> would certainly be preferable if we could centralize the hook call.

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

thanks,

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