I must admit that I don't feel very comfortable about this.  I wonder

how many more flags we might be tempted to add to allow

user-controlled filesystems to do interesting things.  Somehow I doubt

this will be the last, so we should be very careful allowing it to be

the first (or is it the second already?)
A more concrete comment on the patch:  Is it really necessary to

introduce IS_MNT_NODEV??  Why not simply test both the flags

(MS_MKNOD_NOCAP and MNT_NODEV) before allowing the mknod?  That would

localise the change to where is it really relevant.
Do we actually need a new flag?  Would not a combination of MS_NODEV

and MS_SETUSER achieve the same thing (near enough)?
Do you imagine this flag being set as a mount option (-o unprivmknod)

or does the filesystem set it itself?

If the latter, maybe this test should be moved down into the

filesystems ->mknod operation.  Most filesystems get
	if ((S_ISCHR(mode) || S_ISBLK(mode)) && !capable(CAP_MKNOD))

 		return -EPERM;
at the top of ->mknod.  fuse can do whatever it likes without

bothering common code.
According to fs.h, we only support 32 fs-independent mount-flags, and

over half are in use.  I'm not convinced we should spend one on such a

narrow requirement.
-

Or third ;)
Yes, I've always argued, that permission checking needs to be pushed

to the filesystem, since the VFS can't always do a good enough job.
My usual example is sshfs, where it is just impossible to know the

uid/gid mapping between the server and the client.  So any permission

checking based on uid or gid on the client simply can't work, the only

sane thing to do is to delegate the permission checking to the server.

Which works beautifully, since the server is an unprivileged process,

and everything automatically works out.
All the fuse kernel module has to do is to basically define

->permission() to always return success, and let the userspace

filesystem do the permission checking.
This works fine, except a couple of things, like checking the sticky
Because we need MNT_NODEV on _all_ mounts belonging to a superblock,

not just the one on which mknod was performed on, which would get

really ugly.  This way it's simple: if the MS_MKNOD_NOCAP is specified
I imagine this flag to usually be set by the filesystem itself.  But

it could be a separate mount option.  I guess it could make sense in
Yes, that's one of the options, but it would be a huge change, with
I think there's consensus on the need for a new mount API.  Not just

because the 32 bits for the flags will be exhausted sooner or later

anyway, but the current API is limited in lots of other ways.
Miklos

-