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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 5/3/05, Miklos Szeredi <[email protected]> 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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux