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

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

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.

Eric

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