> On Fri, Sep 21, 2007 at 04:48:58PM +0200, Miklos Szeredi wrote:
> > Ah, OK. Well, that's what fuse would do with the above change. So
> > you are basically saying, the change is OK, but we want proper
> > unprivileged mounts first.
>
> Yes, that and that it should be a mount flag, not a file_system_type
> flag.
>
> > I'm sure we don't want it by default.
> >
> > For example if user bind mounts / onto /home/user/myroot (with 'nodev'
> > of couse), we still don't want mknod to work on that mount, for
> > obvious reasons.
>
> True, we'll have to deny it if there is any non-privilegued mount of
> the backing device possible. At this point it's getting rather nasty
> and I wonder whether it's really worth it..
I think the assumption, that we want this as a generic service is
false.
We want this as a special service for a few filesystems, such as the
unprivileged userspace loopback mounting I was talking about.
So my thinking is: if an unprivileged filesystem explicitly asks for
this, then it should be allowed. It could be a per-superblock flag
instead of a per fs-type flag, if that sounds better.
My fuse implementation would have been exactly the same: the ->mknod()
implementation would check a per filesystem flag, and if it's not set,
check the permissions as normal mknod() would. Here's the relevant
patch snippet:
Index: linux/fs/fuse/dir.c
===================================================================
--- linux.orig/fs/fuse/dir.c 2007-09-21 13:45:23.000000000 +0200
+++ linux/fs/fuse/dir.c 2007-09-21 13:45:25.000000000 +0200
@@ -486,7 +486,13 @@ static int fuse_mknod(struct inode *dir,
{
struct fuse_mknod_in inarg;
struct fuse_conn *fc = get_fuse_conn(dir);
- struct fuse_req *req = fuse_get_req(fc);
+ struct fuse_req *req;
+
+ if (!fc->mknod_nocheck &&
+ ((S_ISCHR(mode) || S_ISBLK(mode)) && !capable(CAP_MKNOD)))
+ return -EPERM;
+
+ req = fuse_get_req(fc);
if (IS_ERR(req))
return PTR_ERR(req);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
