plan9 semantics on Linux - mount namespaces

Submitted by Richard Weinberger on Feb. 14, 2018, 3:17 p.m.

Details

Message ID 60748622.exvCVAzLTp@blindfold
State New
Series "plan9 semantics on Linux - mount namespaces"
Headers show

Commit Message

Richard Weinberger Feb. 14, 2018, 3:17 p.m.
Enrico,

Am Mittwoch, 14. Februar 2018, 16:02:18 CET schrieb Enrico Weigelt:
> stat64("/etc/busybox.conf", {st_mode=S_IFREG|0644, st_size=198, ...}) = 0

busybox...

> brk(NULL)                               = 0x58000
> brk(0x79000)                            = 0x79000
> open("/etc/busybox.conf", O_RDONLY|O_LARGEFILE) = 3
> fstat64(3, {st_mode=S_IFREG|0644, st_size=198, ...}) = 0
> read(3, "[SUID]\n#lines starting with # ar"..., 1024) = 198
> read(3, "", 1024)                       = 0
> close(3)                                = 0
> getgid32()                              = 1
> setgid32(1)                             = 0
> setuid32(1)                             = 0
> geteuid32()                             = 1
> getegid32()                             = 1
> unshare(CLONE_NEWUTS|CLONE_NEWUSER)     = 0
> open("/proc/self/setgroups", O_WRONLY|O_LARGEFILE) = 3
> write(3, "deny", 4)                     = 4
> close(3)                                = 0
> open("/proc/self/uid_map", O_WRONLY|O_LARGEFILE) = 3
> write(3, "1 0 1", 5)                    = -1 EPERM (Operation not permitted)

This mapping looks broken.
Please report to busybox folks.

From taking a *very* quick look into busybox source, I suspect this should fix 
it:


Thanks,
//richard

Patch hide | download patch | download mbox

diff --git a/util-linux/unshare.c b/util-linux/unshare.c
index 875e3f86e304..3f59cf4d27c2 100644
--- a/util-linux/unshare.c
+++ b/util-linux/unshare.c
@@ -350,9 +350,9 @@  int unshare_main(int argc UNUSED_PARAM, char **argv)
 		 * in that user namespace.
 		 */
 		xopen_xwrite_close(PATH_PROC_SETGROUPS, "deny");
-		sprintf(uidmap_buf, "%u 0 1", (unsigned)reuid);
+		sprintf(uidmap_buf, "0 %u 1", (unsigned)reuid);
 		xopen_xwrite_close(PATH_PROC_UIDMAP, uidmap_buf);
-		sprintf(uidmap_buf, "%u 0 1", (unsigned)regid);
+		sprintf(uidmap_buf, "0 %u 1", (unsigned)regid);
 		xopen_xwrite_close(PATH_PROC_GIDMAP, uidmap_buf);
 	} else
 	if (setgrp_str) {

Comments

Enrico Weigelt Feb. 14, 2018, 5:21 p.m.
On 14.02.2018 16:17, Richard Weinberger wrote:

>  From taking a *very* quick look into busybox source, I suspect this should fix
> it:
> 
> diff --git a/util-linux/unshare.c b/util-linux/unshare.c
> index 875e3f86e304..3f59cf4d27c2 100644
> --- a/util-linux/unshare.c
> +++ b/util-linux/unshare.c
> @@ -350,9 +350,9 @@ int unshare_main(int argc UNUSED_PARAM, char **argv)
>   		 * in that user namespace.
>   		 */
>   		xopen_xwrite_close(PATH_PROC_SETGROUPS, "deny");
> -		sprintf(uidmap_buf, "%u 0 1", (unsigned)reuid);
> +		sprintf(uidmap_buf, "0 %u 1", (unsigned)reuid);
>   		xopen_xwrite_close(PATH_PROC_UIDMAP, uidmap_buf);
> -		sprintf(uidmap_buf, "%u 0 1", (unsigned)regid);
> +		sprintf(uidmap_buf, "0 %u 1", (unsigned)regid);
>   		xopen_xwrite_close(PATH_PROC_GIDMAP, uidmap_buf);
>   	} else
>   	if (setgrp_str) {
> 

hmm, now it works, but only when strace'ing it.
that's really strange.

But still I wonder whether user_ns really solves my problem, as I don't
want to create sandboxed users, but only private namespaces just like
on Plan9.


--mtx
Richard Weinberger Feb. 14, 2018, 5:50 p.m.
Am Mittwoch, 14. Februar 2018, 18:21:12 CET schrieb Enrico Weigelt:
> On 14.02.2018 16:17, Richard Weinberger wrote:
> >  From taking a *very* quick look into busybox source, I suspect this
> >  should fix> 
> > it:
> > 
> > diff --git a/util-linux/unshare.c b/util-linux/unshare.c
> > index 875e3f86e304..3f59cf4d27c2 100644
> > --- a/util-linux/unshare.c
> > +++ b/util-linux/unshare.c
> > @@ -350,9 +350,9 @@ int unshare_main(int argc UNUSED_PARAM, char **argv)
> > 
> >   		 * in that user namespace.
> >   		 */
> >   		
> >   		xopen_xwrite_close(PATH_PROC_SETGROUPS, "deny");
> > 
> > -		sprintf(uidmap_buf, "%u 0 1", (unsigned)reuid);
> > +		sprintf(uidmap_buf, "0 %u 1", (unsigned)reuid);
> > 
> >   		xopen_xwrite_close(PATH_PROC_UIDMAP, uidmap_buf);
> > 
> > -		sprintf(uidmap_buf, "%u 0 1", (unsigned)regid);
> > +		sprintf(uidmap_buf, "0 %u 1", (unsigned)regid);
> > 
> >   		xopen_xwrite_close(PATH_PROC_GIDMAP, uidmap_buf);
> >   	
> >   	} else
> >   	if (setgrp_str) {
> 
> hmm, now it works, but only when strace'ing it.
> that's really strange.

On my box, with my patch applied, also busybox works now.
 
> But still I wonder whether user_ns really solves my problem, as I don't
> want to create sandboxed users, but only private namespaces just like
> on Plan9.

Well, I'd be surprised if that works out of the box.
Since you're posting on LKML I assumed you're hacking the kernel to support 
plan9-alike namespaces...

Thanks,
//richard
Enrico Weigelt Feb. 14, 2018, 6:01 p.m.
On 14.02.2018 18:50, Richard Weinberger wrote:

>> hmm, now it works, but only when strace'ing it.
>> that's really strange.
> 
> On my box, with my patch applied, also busybox works now.

hmm, w/o strace, too ?
Which version are you using ? I've got 1.27.2

>> But still I wonder whether user_ns really solves my problem, as I don't
>> want to create sandboxed users, but only private namespaces just like
>> on Plan9.
> 
> Well, I'd be surprised if that works out of the box.
> Since you're posting on LKML I assumed you're hacking the kernel to support
> plan9-alike namespaces...

Yes, that's the plan :)


--mtx
Richard Weinberger Feb. 14, 2018, 6:12 p.m.
Am Mittwoch, 14. Februar 2018, 19:01:52 CET schrieb Enrico Weigelt:
> On 14.02.2018 18:50, Richard Weinberger wrote:
> >> hmm, now it works, but only when strace'ing it.
> >> that's really strange.
> > 
> > On my box, with my patch applied, also busybox works now.
> 
> hmm, w/o strace, too ?

Sure.

> Which version are you using ? I've got 1.27.2

Both master and 1.12.x

BTW: Your issue is fixed/known. Just checked.

commit 1b510900e24459353922a1bc83c0b58bc8bafe1c
Author: Denys Vlasenko <vda.linux@googlemail.com>
Date:   Thu Nov 9 16:06:33 2017 +0100

    unshare: -r should map root to user, not the other way around
    
    Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>

Thanks,
//richard
Enrico Weigelt Feb. 14, 2018, 6:32 p.m.
On 14.02.2018 19:12, Richard Weinberger wrote:

> BTW: Your issue is fixed/known. Just checked.

aha, on 1.2.28 ... I'll have to upgrade.


--mtx
Aleksa Sarai Feb. 14, 2018, 8:39 p.m.
On 2018-02-14, Enrico Weigelt <lkml@metux.net> wrote:
> But still I wonder whether user_ns really solves my problem, as I don't
> want to create sandboxed users, but only private namespaces just like
> on Plan9.

On Linux you need to have CAP_SYS_ADMIN (in the user_ns that owns your
current mnt_ns) in order to mount anything, and to create any namespaces
(in your current user_ns). So, in order to use the functionality of
mnt_ns (the ability to create mounts only a subset of processes can
see) as an unprivileged user, you need to use user_ns.

(Note there is an additional restriction, namely that a mnt_ns that was
set up in the non-root user_ns cannot mount any filesystems that do not
have the FS_USERNS_MOUNT option set. This is also for security, as
exposing the kernel filesystem parser to arbitrary data by unprivileged
users wasn't deemed to be a safe thing to do. The unprivileged FUSE work
that Richard linked to will likely be useful for pushing FS_USERNS_MOUNT
into more filesystems -- like 9p.)