user_ns: Add support for unprivileged remount

From: Zhao Hongjiang <[email protected]>

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.

Quoted 5 lines · Zhao Hongjiang

From: Zhao Hongjiang <[email protected]>

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

Quoted 11 lines · Eric W. Biederman

Quoted 5 lines · Zhao Hongjiang

From: Zhao Hongjiang <[email protected]>

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.

Quoted 3 lines

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?

Quoted 12 lines · Zhao Hongjiang

Quoted 11 lines · Eric W. Biederman

Quoted 5 lines · Zhao Hongjiang

From: Zhao Hongjiang <[email protected]>

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.

Quoted 7 lines

Quoted 3 lines

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.

Quoted 35 lines · Eric W. Biederman

Quoted 12 lines · Zhao Hongjiang

Quoted 11 lines · Eric W. Biederman

Quoted 5 lines · Zhao Hongjiang

From: Zhao Hongjiang <[email protected]>

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.

Quoted 7 lines

Quoted 3 lines

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.

Quoted 7 lines

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!

From 8c5a01c007d72c748018665d3bd27cd2bde52c0f Mon Sep 17 00:00:00 2001
From: Gao feng <[email protected]>
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 <[email protected]>

---
 fs/namespace.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

fs/namespace.c +0 -0

index 55605c5..b9d83fb 100644
@@ -1748,7 +1748,10 @@ static int do_remount(struct path *path, int flags, int mnt_flags,
 	struct super_block *sb = path->mnt->mnt_sb;

Quoted 43 lines · Gao feng

Quoted 35 lines · Eric W. Biederman

Quoted 12 lines · Zhao Hongjiang

Quoted 11 lines · Eric W. Biederman

Quoted 5 lines · Zhao Hongjiang

From: Zhao Hongjiang <[email protected]>

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.

Quoted 7 lines

Quoted 3 lines

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.

Quoted 7 lines

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.

Quoted 5 lines

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
---

Quoted 24 lines

Thanks!

From 8c5a01c007d72c748018665d3bd27cd2bde52c0f Mon Sep 17 00:00:00 2001
From: Gao feng <[email protected]>
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 <[email protected]>

---
 fs/namespace.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

fs/namespace.c +0 -0

index 55605c5..b9d83fb 100644
@@ -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);
 

fs/namespace.c static int do_remount(struct path *path, int flags, int mnt_flags, · line 1757

Quoted 8 lines

fs/namespace.c +4 -1

-	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))

Quoted 63 lines · Eric W. Biederman

Quoted 43 lines · Gao feng

Quoted 35 lines · Eric W. Biederman

Quoted 12 lines · Zhao Hongjiang

Quoted 11 lines · Eric W. Biederman

Quoted 5 lines · Zhao Hongjiang

From: Zhao Hongjiang <[email protected]>

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.

Quoted 7 lines

Quoted 3 lines

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.

Quoted 7 lines

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.

Quoted 5 lines

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.

Quoted 8 lines

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.