Re: [PATCH] user_ns: Add support for unprivileged remount

[ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org (Eric W. Biederman)]

Gao feng <gaofeng@cn.fujitsu.com> writes:

> On 2013/01/17 18:06, Eric W. Biederman wrote:
>> Gao feng <gaofeng@cn.fujitsu.com> writes:
>> 
>>> On 2012/09/14 17:33, Eric W. Biederman wrote:
>>>> Zhao Hongjiang <zhaohongjiang37@gmail.com> writes:
>>>>
>>>>> On 2012-9-14 5:26, Eric W. Biederman wrote:
>>>>>> Zhao Hongjiang <zhaohongjiang37@gmail.com> writes:
>>>>>>
>>>>>>> From: Zhao Hongjiang <zhaohongjiang@huawei.com>
>>>>>>>
>>>>>>> Relax the permission checks to allow unprivileged users that have
>>>>>>> CAP_SYS_ADMIN permissions in the user namespace referred to by the
>>>>>>> current mount namespace to be allowed to remount filesystems.
>>>>>>
>>>>>> Remount in general make filesystem configuration changes not mount level
>>>>>> changes.
>>>>>>
>>>>>> In general remount is not safe for unprivielged users.
>>>>>>
>>>>>> Do you have a use case where you need to remount a filesystem?
>>>>>
>>>>> As we can do a umount+mount，I don't see why remount operation is not allowed.
>>>>> Shouldn't we add checks in remount path in the specific filesystem to ensure
>>>>> safety instead when we enable unprivilleged mount?
>>>>
>>>> But the thing is remount != mount+umount.  Remount is change lowlevel
>>>> filesystem options.
>>>>
>>>> The basic danger is if someone in the primary user namespace mounted a
>>>> filesystem, and then we cloned that filesystem.
>>>>
>>>> umounting filesystems is ok.  There reference count will drop or they
>>>> will just unmount if the ref count goes to zero.
>>>>
>>>> However mount -o remount -r /home could very easily remount everyone's
>>>> home directory in all mount namespaces read-only by making the
>>>> filesystem itself readonly.
>>>>
>>>> That danger applies even to some extent even if the options are safe for
>>>> us to perform at the filesystem level.
>>>>
>>>> Now that doesn't mean remount is a hopeless operation.  What it does
>>>> mean is that we need to be very carefully with enabling remounting
>>>> of a filesystem.
>>>>
>>> Hi Eric
>>>
>>> what's you idea about the patch below.
>>> Maybe it better to add a new fs_flags FS_USERNS_REMOUNT?
>>> It's not a good experience that remount is disabled in container.
>> 
>> I think you totally did not read and understand what I said above,
>> and your patch description is wrong.
>> 
>> Remounting proc is not safe, making the patch below is broken.  Read
>> proc and read my comments above.
>> 
>> Thinking that this might be an issue that can be fixed with fs_flags is
>> thinking about this wrong.  Thinking a remount in any way would be
>> isolated to a single mount namespaces is wrong.  When implementing
>> remount you have to think about everyone who has access to that
>> filesystem, and is is legitimate for you to affect all of them.
>> 
>> What are people doing with remounting?  Why do we want it?  As a
>> practical matter, assume that it is impossible to resue the current
>> filesystem level implementation of remount.
>> 
>> As I said above I don't even think mount -o remount -r /some/filesystem
>> is safe.  Think what would happen if you run the shell script below with
>> /tmp being a separate tmpfs mount point and /proc being procfs.
>> 
>
>
> Thanks for you explanation,You mean the super-block may be shared within
> two mntns,And allowing owner of the mntns which maybe unprivileged user
> to remount this filesystem will affect the other mntns.
> I'm right?

Yes.

> Such as proc filesystem,the root user of mntns may umount and then mount
> it again.So the super block will not be shared with other,In this situation,
> we can allow this root user to remount the proc filesystem.

Given that there is exactly one proc mount per pid namespace I don't
think your argument exactly holds up.

> I think we may need a flag such as MS_SHARED_NS to point out if this super
> block is shared by may mntns.if the super block is only owned by one mntns,
> we can allow the root user of this mntns to remount the filesystem.

mount namespaces can't own anything and with mount propogation and the
fact unsharing the mount namespace copies all mounts it is hard to keep
any mount in a single mount namespace.

You can think of user namespace ownership.  Especially since user
namespaces form a tree, so even filesystems that are the most user
namespace friendly should have a user namespace that could be considered
their owner.

With those caveats I agree that with the appropriate permissions in the
user namespace that owns the underlying object remounts should be fine.

Also remounts with MS_BIND specified should be as safe as mounts and
unmounts are.

Eric

_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/containers