Messages in this thread | | | Date | Wed, 4 May 2005 08:08:00 -0500 | From | Eric Van Hensbergen <> | Subject | Re: [RCF] [PATCH] unprivileged mount/umount |
| |
On 5/3/05, Miklos Szeredi <miklos@szeredi.hu> wrote: > This (lightly tested) patch against 2.6.12-rc* adds some > infrastructure and basic functionality for unprivileged mount/umount > system calls. > > Details: > > - new mnt_owner field in struct vfsmount > - if mnt_owner is NULL, it's a privileged mount > - global limit on unprivileged mounts in /proc/sys/fs/mount-max > - per user limit of mounts in rlimit
I was starting down this track in my tree, but I'm glad you beat me to it ;). Your initial limit (10) seems low if you consider binds as mounts. I can easily see a user using more than 10 binds in an environment. As Ram mentioned earlier - we are going to run into problems with the shared-subtree stuff if propagations into private namespaces count as a new mount. We need to think through how we are going to deal with this.
> - allow umount for the owner (except force flag) > - allow unprivileged bind mount to files/directories writable by owner > - add nosuid,nodev flags to unprivileged mounts > > Next step would be to add some policy for new mounts. I'm thinking of > either something static: e.g. FS_SAFE flag for "safe" filesystems, or > a more configurable approach through sysfs or something. >
I think the FS_SAFE stuff needs to be part of this patch. Folks made a pretty good argument that mounting corrupted images with certain file systems could be a really bad thing. I'm not sure on the whole sysfs configurable approach -- it seems like more advanced policies would be best handled in user-space.
My major complaint is that I really think having user mounts without requiring them to be in a user's private namespace creates quite a mess. It potentially pollutes the system's namespace and opens up the possibility of all sorts of synthetic file system "traps". I'd rather see the private namespace stuff enforced before enabling user-mounts.
-eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |