Re: [PATCH-RFC] code for raceless /sys/fs/foofs/*

[Nikita Danilov]

viro@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx writes:
 > On Wed, May 05, 2004 at 05:28:03PM +0100, viro@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx wrote:
 > > On Wed, May 05, 2004 at 05:53:16PM +0400, Nikita Danilov wrote:
 > > > Hello,
 > > > 
 > > > attached patch adds code necessary to safely export per-super-block
 > > > information in /sys/fs and /proc/fs.
 > > > 
 > > > Common problem with exporting file system information in procfs or sysfs
 > > > is a race between method that inputs/outputs data and concurrent umount
 > > > of the super-block involved.
 > >  
 > > Aside of the implementation questions (will comment later), there is an
 > > interface problem here.  We end up allowing anyone who has sysfs mounted
 > > (in chroot jail, in limited namespace, etc.) to pin down _any_ reiser4
 > > superblock, whether they have the thing itself mounted or not.
 > 
 > [sorry about truncated message - -ENOCOFFEE hits]
 > 
 > We also allow anyone with sysfs mounted to see which filesystems are currently
 > mounted on the box - again, regardless of being able to see them in the
 > chroot jail/restricted namespace/etc.  It can easily become an issue in
 > setups where such information is sensitive.

But isn't this a problem with sysfs in general? Restricted process still
observes all devices, busses, etc. through /sys. If such information is
sensitive, shouldn't there be some way to selectively mount only
portions of kobject trees? For example, when file system is mounted, its
/sys/fs/foofs/sb-id tree is mounted in the same namespace. That is, we
need something like

    int sysfs_mount(struct kobject *root, char *mountpoint);


What I am concerned about is that building special foofs-meta
file-system on top of fs/libfs.c for each file-system foofs would lead
to the code duplication, while sysfs/kobjects already have all the
paraphernalia in place.

Nikita.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/