Re: [patch] inode_init hook

sdsat_private

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.
devpts is likely to remain a special case anyway, since devpts_pty_new is
called from tty_open() on the ptmx device, and we want to initialize its
security information at that point based on the opening process.

--
Stephen D. Smalley, NAI Labs
ssmalleyat_private

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