Re: [RCF] [PATCH] unprivileged mount/umount

Eric Van Hensbergen
2005-05-04T13:08:11Z

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