[Toybox] unshare/nsenter and flags

[Rob Landley]

Ok, cycling back to this...

On 5/2/24 21:51, enh wrote:
>> > it seems like -r _doesn't_ actually imply -U in practice (and they
>> > seemed to have strace output to prove it).
>>
>> So... should it?
> 
> i think so? i have no idea about any of this, but
> https://man7.org/linux/man-pages/man1/unshare.1.html says
> 
>        -r, --map-root-user
>            Run the program only after the current effective user and
>            group IDs have been mapped to the superuser UID and GID in
>            the newly created user namespace. This makes it possible to
>            conveniently gain capabilities needed to manage various
>            aspects of the newly created namespaces (such as configuring
>            interfaces in the network namespace or mounting filesystems
>            in the mount namespace) even when run unprivileged. As a mere
>            convenience feature, it does not support more sophisticated
>            use cases, such as mapping multiple ranges of UIDs and GIDs.
>            This option implies --setgroups=deny and --user. This option
>            is equivalent to --map-user=0 --map-group=0.
> 
> which sounds like it supports the toybox documentation rather than the
> toybox source?
> 
>> What did they try to do, and what did they _want_ to happen?
> 
> unshare --mount --map-root-user /bin/sh -c "mount --bind $A $B"

Running that as my normal user gave EPERM on the unshare(CLONE_NEWNS) which is
the reason I haven't poked at this more. (To be useful, it seems like it
probably needs to be setuid and then drop permissions after unsharing stuff, and
I need to come up to speed on the security implications of that and possibly
write a "contain" command with as little novelty as possible. Which is not a can
of worms I want to open without a clear desk...)

Running it under sudo I got:

openat(AT_FDCWD, "/proc/self/setgroups", O_WRONLY) = 3
write(3, "deny", 4)                     = -1 EPERM (Operation not permitted)

> they looked at strace for toybox and saw
> 
> unshare(CLONE_NEWNS)                    = -1 EPERM (Operation not permitted)
> 
> but for the util-linux one they saw
> 
> unshare(CLONE_NEWNS|CLONE_NEWUSER)      = 0

Are they root or a normal user? Because adding -U to the above command line I got:

geteuid()                               = 1000
getegid()                               = 1000
unshare(CLONE_NEWNS|CLONE_NEWUSER)      = -1 EPERM (Operation not permitted)

But with sudo, that succeeded and adding an ls -l to the bash command yes it did
the bind mount, which is gone again when it exits.

>> The "22.04" means it came out two years and one month ago, and that's what
>> they're migrating me TO. So, you know, I can presumably feel less bad about my
>> laptop...
> 
> (to be fair, until _last week_ that was the current LTS release :-)
> but, yeah, odd timing unless they deliberately like to be on the
> previous LTS release! i'll throw no stones as long as i'm living so
> close to the Android build server glass house though...)

Got about half my laptop tabs closed so far! Working towards a reboot...

Rob