[PATCH] user_ns: Add support for unprivileged remount

[PATCH] user_ns: Add support for unprivileged remount

[Zhao Hongjiang]

From: Zhao Hongjiang <zhaohongjiang-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>

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.

Signed-off-by: Zhao Hongjiang <zhaohongjiang-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
---
 fs/namespace.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/fs/namespace.c b/fs/namespace.c
index af238d0..72be266 100644
--- a/fs/namespace.c
+++ b/fs/namespace.c
@@ -1748,7 +1748,7 @@ static int do_remount(struct path *path, int flags, int mnt_flags,
 	struct super_block *sb = path->mnt->mnt_sb;
 	struct mount *mnt = real_mount(path->mnt);

-	if (!capable(CAP_SYS_ADMIN))
+	if (!ns_capable(mnt->mnt_ns->user_ns, CAP_SYS_ADMIN))
 		return -EPERM;

 	if (!check_mnt(mnt))
-- 1.7.1

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

[Eric W. Biederman]

Zhao Hongjiang <zhaohongjiang37-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:

> From: Zhao Hongjiang <zhaohongjiang-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
>
> 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?

Eric

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

[Zhao Hongjiang]

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?

> 
> Eric
> 

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

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

[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

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

[Gao feng]

[-- Attachment #1: Type: text/plain, Size: 2047 bytes --]

On 2012/09/14 17:33, Eric W. Biederman wrote:
> Zhao Hongjiang <zhaohongjiang37-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
> 
>> On 2012-9-14 5:26, Eric W. Biederman wrote:
>>> Zhao Hongjiang <zhaohongjiang37-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
>>>
>>>> From: Zhao Hongjiang <zhaohongjiang-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
>>>>
>>>> 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!

[-- Attachment #2: 0001-userns-allow-remount-filesystem-in-un-init-userns.patch --]
[-- Type: text/x-patch, Size: 1079 bytes --]

From 8c5a01c007d72c748018665d3bd27cd2bde52c0f Mon Sep 17 00:00:00 2001
From: Gao feng <gaofeng-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org>
Date: Thu, 17 Jan 2013 14:41:00 +0800
Subject: [PATCH] userns: allow remount filesystem in un-init userns

The proc and sysfs filesystem already enable userns support,
remounting these filesystems in un-init userns do no harm
to the host.

Signed-off-by: Gao feng <gaofeng-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org>
---
 fs/namespace.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/fs/namespace.c b/fs/namespace.c
index 55605c5..b9d83fb 100644
--- a/fs/namespace.c
+++ b/fs/namespace.c
@@ -1748,7 +1748,10 @@ static int do_remount(struct path *path, int flags, int mnt_flags,
 	struct super_block *sb = path->mnt->mnt_sb;
 	struct mount *mnt = real_mount(path->mnt);
 
-	if (!capable(CAP_SYS_ADMIN))
+	if (sb->s_type->fs_flags & FS_USERNS_MOUNT) {
+		if (!ns_capable(mnt->mnt_ns->user_ns, CAP_SYS_ADMIN))
+			return -EPERM;
+	} else if (!capable(CAP_SYS_ADMIN))
 		return -EPERM;
 
 	if (!check_mnt(mnt))
-- 
1.7.11.7


[-- Attachment #3: Type: text/plain, Size: 205 bytes --]

_______________________________________________
Containers mailing list
Containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
https://lists.linuxfoundation.org/mailman/listinfo/containers

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

[Eric W. Biederman]

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.

---
#!/bin/sh
export IFIFO=/tmp/pidns-test-$$-in
export OFIFO=/tmp/pidns-test-$$-out
rm -f $IFIFO $OFIFO
mkfifo $IFIFO
mkfifo $OFIFO
unshare --user -- /bin/bash -s <<'EOF' &
echo waiting-for-uid-and-gid-maps > $OFIFO
read LINE < $IFIFO
exec unshare --mount -- /bin/bash -s <<'EOF2'

mount -n -o remount -ro /tmp
mount -n -o remount /proc hidpide=2

EOF2
EOF
child=$!
read LINE < $OFIFO
uid=$(id --user)
gid=$(id --group)
echo "0 $uid 1" > /proc/$child/uid_map
echo "0 $gid 1" > /proc/$child/gid_map
echo uid-and-gid-maps > $IFIFO
wait $child
---

> Thanks!
>
> From 8c5a01c007d72c748018665d3bd27cd2bde52c0f Mon Sep 17 00:00:00 2001
> From: Gao feng <gaofeng@cn.fujitsu.com>
> Date: Thu, 17 Jan 2013 14:41:00 +0800
> Subject: [PATCH] userns: allow remount filesystem in un-init userns
>
> The proc and sysfs filesystem already enable userns support,
> remounting these filesystems in un-init userns do no harm
> to the host.
>
> Signed-off-by: Gao feng <gaofeng@cn.fujitsu.com>
> ---
>  fs/namespace.c | 5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/fs/namespace.c b/fs/namespace.c
> index 55605c5..b9d83fb 100644
> --- a/fs/namespace.c
> +++ b/fs/namespace.c
> @@ -1748,7 +1748,10 @@ static int do_remount(struct path *path, int flags, int mnt_flags,
>  	struct super_block *sb = path->mnt->mnt_sb;
>  	struct mount *mnt = real_mount(path->mnt);
>  
> -	if (!capable(CAP_SYS_ADMIN))
> +	if (sb->s_type->fs_flags & FS_USERNS_MOUNT) {
> +		if (!ns_capable(mnt->mnt_ns->user_ns, CAP_SYS_ADMIN))
> +			return -EPERM;
> +	} else if (!capable(CAP_SYS_ADMIN))
>  		return -EPERM;
>  
>  	if (!check_mnt(mnt))
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/containers

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

[Gao feng]

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?

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.


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.

Thanks.
> ---
> #!/bin/sh
> export IFIFO=/tmp/pidns-test-$$-in
> export OFIFO=/tmp/pidns-test-$$-out
> rm -f $IFIFO $OFIFO
> mkfifo $IFIFO
> mkfifo $OFIFO
> unshare --user -- /bin/bash -s <<'EOF' &
> echo waiting-for-uid-and-gid-maps > $OFIFO
> read LINE < $IFIFO
> exec unshare --mount -- /bin/bash -s <<'EOF2'
> 
> mount -n -o remount -ro /tmp
> mount -n -o remount /proc hidpide=2
> 
> EOF2
> EOF
> child=$!
> read LINE < $OFIFO
> uid=$(id --user)
> gid=$(id --group)
> echo "0 $uid 1" > /proc/$child/uid_map
> echo "0 $gid 1" > /proc/$child/gid_map
> echo uid-and-gid-maps > $IFIFO
> wait $child
> ---
> 
>> Thanks!
>>
>> From 8c5a01c007d72c748018665d3bd27cd2bde52c0f Mon Sep 17 00:00:00 2001
>> From: Gao feng <gaofeng@cn.fujitsu.com>
>> Date: Thu, 17 Jan 2013 14:41:00 +0800
>> Subject: [PATCH] userns: allow remount filesystem in un-init userns
>>
>> The proc and sysfs filesystem already enable userns support,
>> remounting these filesystems in un-init userns do no harm
>> to the host.
>>
>> Signed-off-by: Gao feng <gaofeng@cn.fujitsu.com>
>> ---
>>  fs/namespace.c | 5 ++++-
>>  1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/fs/namespace.c b/fs/namespace.c
>> index 55605c5..b9d83fb 100644
>> --- a/fs/namespace.c
>> +++ b/fs/namespace.c
>> @@ -1748,7 +1748,10 @@ static int do_remount(struct path *path, int flags, int mnt_flags,
>>  	struct super_block *sb = path->mnt->mnt_sb;
>>  	struct mount *mnt = real_mount(path->mnt);
>>  
>> -	if (!capable(CAP_SYS_ADMIN))
>> +	if (sb->s_type->fs_flags & FS_USERNS_MOUNT) {
>> +		if (!ns_capable(mnt->mnt_ns->user_ns, CAP_SYS_ADMIN))
>> +			return -EPERM;
>> +	} else if (!capable(CAP_SYS_ADMIN))
>>  		return -EPERM;
>>  
>>  	if (!check_mnt(mnt))
> 

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

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

[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