[PATCH] user_ns: Add support for unprivileged remount

[Gao feng]

On 2012/09/14 17:33, Eric W. Biederman wrote:
> Zhao Hongjiang <zhaohongjiang37 at gmail.com> writes:
> 
>> On 2012-9-14 5:26, Eric W. Biederman wrote:
>>> Zhao Hongjiang <zhaohongjiang37 at gmail.com> writes:
>>>
>>>> From: Zhao Hongjiang <zhaohongjiang at 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.

Thanks!