[Toybox] Using toybox for poking around weird namespaces?

[Andy Lutomirski]

On Thu, Oct 23, 2014 at 5:21 PM, Rob Landley <rob at landley.net> wrote:
> On 10/16/14 20:17, Andy Lutomirski wrote:
>> Toybox's magical ability to present a usable shell without needing to
>> exec anything is almost perfect for poking around in a namespace.  The
>> only real missing piece is how to get into the namespace in the first
>> place.
>
> Sorry for the delay on this one, you posted this before subscribing and
> I only clean out the spam filter infrequently. (There were about 50 spam
> and two good emails since last time.)
>
>> Would it make sense to add some optional top-level command-line
>> options to enable this?  For example:
>>
>> toybox --userns=/proc/whatever/user --uid=x --gid=y
>>
>> Alternatively, if toybox were to implement nsenter and setpriv, it
>> would get this for free.  (I own copyright on a large portion of
>> setpriv, and I would be happy to relicense it.)  Then we could do:
>>
>> toybox nsenter --whatever setpriv --whatever sh
>>
>> and it might all just work.
>>
>> Thoughts?
>>
>> --Andy
>
> I believe you already submitted nsenter (which I merged but got
> distracted halfway through cleaning up. I can probably finish cleanup
> this weekend). I don't remember setpriv, but it sounds like fun. (What
> does it do?)

setpriv is a low-level tool to read and change various Linux security
things.  It can set real/effective uid/gid, auxiliary groups,
inheritable caps, cap bounding set, securebits, selinux context,
apparmor context, and no_new_privs.

>
> Yes, the correct way to do it would be ala:
>
>   ./toybox renice -n 5 nsenter --walrus setpriv --thingy setsid nohup \
>     env -i time netcat tL -p 9876 echo hello world
>
> I.E. wrapper commands that exec their arguments. A fairly established
> pattern. (sudo! detach! Don't ask me why Eric Raymond decided this was
> named "bernstein chaining" in The Art of Unix Programming, I argued
> against it at the time. It predates that guy by 15 years. It's just a
> wrapper command.)
>
> And it's one of the reasons xexec() has a counter and does an actual
> exec() instead of just recursive command_main() calls after a certain
> number of levels. Otherwise "time time time time time time time time"
> could get a bit annoying. Not _hugely_ so because Linux caps environment
> space at 32 pages so 128k total, including environment variables and
> arguments _and_ the "char *[]" arrays for argv and envp. (I needed to
> know this to implement xargs properly.) But still, you could chain
> pretty deep and it goes from "optimization" to "silly" after a certain
> point...

Would anything blow up if xexec longjumped back to main?  Or what am I
missing here?  (Probably many things.)

--Andy

 1414110352.0