On Mon, 2007-02-05 at 18:13 -0800, Andreas Gruenbacher wrote: > On Monday 05 February 2007 10:44, Christoph Hellwig wrote: > > Looking at the actual patches I see you're lazy in a lot of places. > > Please make sure that when you introduce a vfsmount argument somewhere > > that it is _always_ passed and not just when it's conveniant. Yes, that's > > more work, but then again if you're not consistant anyone half-serious > > will laught at a security model using this infrasturcture. > > It may appear like laziness, but it's not. Let's look at where we're passing > NULL at the moment: > > fs/hpfs/namei.c > > In hpfs_unlink, hpfs truncates one of its own inodes through > notify_change(). You definitely don't want any lsms to interfere here, > pathname based or not; hpfs should probably truncate its inode itself > instead. But given that hpfs goes via the vfs, we at least pass NULL > to indicate that this file really has no meaningful paths to it > anymore. (In addition, we don't really have a vfsmount at this > point anymore, and neither would it make sense to pass it there.) > > To play more nicely with other lsms, hpfs could mark the inode as > private before attempting the truncate. > > fs/reiserfs/xattr.c > > The directories an files that reiserfs uses internally to store xattrs > are hanging off ".reiserfs_priv/xattrs" in the filesystem. This part > of the namespace is not accessible or visible from user space though > except through the xattr syscalls. > > Reiserfs should probably just mark all its xattr inodes as private in order > to play nicely with other lsms. As far as pathname based lsms are concerned, > pathnames to those fs-internal objects are meaningless though, and so we > pass NULL here. That should be handled by the current marking of reiserfs xattr inodes with S_PRIVATE and the tests for IS_PRIVATE in include/linux/security.h (and in one instance, within SELinux itself). -- Stephen Smalley National Security Agency - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
