Re: [patch 0/8] unprivileged mount syscall

Serge E. Hallyn
2007-04-09T22:00:20Z

Quoting Miklos Szeredi (miklos-sUDqSbJrdHQHWmgEVkV9KA@public.gmane.org):
> This patchset adds support for keeping mount ownership information in
> the kernel, and allow unprivileged mount(2) and umount(2) in certain
> cases.

Well, I'd like to feel all smart and point out some bugs, but the code
all reads very nicely, seems to work as advertised, and while I won't
have ltp results until tomorrow, boot test results in so far are all
successful.

Looks good.

-serge

> This can be useful for the following reasons:
>
> - mount(8) can store ownership ("user=XY" option) in the kernel
> instead, or in addition to storing it in /etc/mtab. For example if
> private namespaces are used with mount propagations /etc/mtab
> becomes unworkable, but using /proc/mounts works fine
>
> - fuse won't need a special suid-root mount/umount utility. Plain
> umount(8) can easily be made to work with unprivileged fuse mounts
>
> - users can use bind mounts without having to pre-configure them in
> /etc/fstab
>
> All this is done in a secure way, and unprivileged bind and fuse
> mounts are disabled by default and can be enabled through sysctl or
> /proc/sys.
>
> One thing that is missing from this series is the ability to restrict
> user mounts to private namespaces. The reason is that private
> namespaces have still not gained the momentum and support needed for
> painless user experience. So such a feature would not yet get enough
> attention and testing. However adding such an optional restriction
> can be done with minimal changes in the future, once private
> namespaces have matured.
>
> An earlier version of these patches have been discussed here:
>
> http://lkml.org/lkml/2005/5/3/64
>
> --
> -
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html