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

[Eric Van Hensbergen <ericvh@gmail.com>]

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/