Quoting Miklos Szeredi (miklos@xxxxxxxxxx):
> This patchset adds support for keeping mount ownership information in
> the kernel, and allow unprivileged mount(2) and umount(2) in certain
> cases.
>
> 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.
What is the main reason for that feature? Would it be to prevent things
like login from being tricked by user mounts? Isn't it sufficient, in
fact, better, to require that the target of the mount be owned by the
user doing the mount?
-serge (who's pretty sure he's missing something)
> 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@xxxxxxxxxxxxxxx
> More majordomo info at http://vger.kernel.org/majordomo-info.html
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
