Re: [patch 00/13] devtmpfs patches

[Stephen Smalley <sds@tycho.nsa.gov>]

On Wed, 2009-05-13 at 14:58 +0200, Kay Sievers wrote:
> On Wed, May 13, 2009 at 14:22, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> 
> > I think you'll actually need to switch credentials around the entire
> > sequence starting from vfs_path_lookup() and going through the
> > vfs_mknod() call in order to avoid any denials from vfs_path_lookup,
> > vfs_mkdir (via create_path), and vfs_mknod.
> >
> > Then the same issue applies to devtmpfs_delete_node() to prevent unlink
> > denials against the current process when a node is removed, similarly
> > wrapping everything from the vfs_path_lookup() through the final
> > delete_path() call.
> 
> Ok, good, will do that. Anything like this to keep in mind when
> creating/removing simple subdirectories?

Yes, any time you call any vfs helper (and thus are subject to the
permission checking calls, both DAC and LSM/SELinux), you need to decide
whether you truly want those permission checks to get applied against
the current process' credentials or whether you should be using
alternate credentials for the call.  If on the other hand you can
perform your operations at a lower level (e.g. direct calls to the
underlying inode operations), then you don't have to be concerned with
the permission checking, but there is still the issue of ownership and
file security labeling for any new files/directories you create, so even
there you may need to establish different credentials to avoid
unwittingly creating those files with the uid/security context of
whatever the current process happens to be.

-- 
Stephen Smalley
National Security Agency