Import nginx code to set process title, use it for "cinit"
When debugging things, it's really useful to be able to see from the process output which thing is which. Here, we're using the term "cinit" for the in-container init.
I looked around on the internets for this - I thought systemd would have a good implementation, but they don't do the requsite trick with malloc to ensure we have enough space. nginx does. Now, I also found https://tycho.ws/blog/2015/02/setproctitle.html but their implementation sounded way more complex.
So, going from the nginx code, I heavily edited it to drop Solaris/FreeBSD etc.
Also, to use xmalloc instead of their allocator, etc.
This just makes things easier to debug; there's a risk though that it's new parsing code that is reachable in the suid case by an attacker outside; I'll do some extra review on this if we agree to take it.
walters 188 0.0 0.0 126328 7896 pts/1 S Jan22 0:12 | \_ -bash
walters 17327 0.0 0.0 13324 1072 pts/1 S 12:39 0:00 | \_ bwrap --unshare-pid --ro-bind / / sleep 1h
walters 17331 0.0 0.0 13324 144 pts/1 S 12:39 0:00 | | \_ bwrap: cinit
walters 17334 0.0 0.0 114540 656 pts/1 S 12:39 0:00 | | \_ sleep 1h
The failure is due to the saved argv/env leak, which i'm not sure we can fix. Can we suppress it?
Anyway, this seems very useful to me. Should we start a stable branch and commit this (and other features) to master? Or maybe this qualifies for "bugfix".
Oh, and do we really need to keep the ngx_ prefix?
If you look at the logs, we have other problems because ASAN gets confused (understandably) by unsharing the PID namespace and forking. I'll look at keeping ASAN enabled, just with leak detection disabled.
Re ngx_...dunno. It's a way of giving them credit, and helping us remember that if we make any bugfixes here to send them "upstream". I don't have a really strong feeling though, if you'd prefer to drop it I can do that.
I prefer to give the credits in comments and have a more logical structure in our code.
Ok, reworked, rebased. :arrow_up:
OK, reading the nginx code, it looks like they were using the cached argv copy so they could later rewrite argv for the master process, e.g. on my system:
root 28007 0.0 0.0 60740 7924 ? Ss 07:10 0:00 \_ nginx: master process /usr/sbin/nginx
Where /usr/sbin/nginx is the sole original argv, but one might also see other things there.
Not sure whether it's worth it; with just what we have now it's pretty obvious that the initial /usr/bin/bwrap is the outer master.
@cgwalters Well, if we're not going to do that, the a lot of the work duplicating the env and argv is completely unnecessary, all we need to do is to figure out exactly how large the area to overwrite is.
Otoh, something like that is bound to bite us in the ass eventually when we accidentally dereference an env-var in the cinit code.
:umbrella: The latest upstream changes (presumably b6370de) made this pull request unmergeable. Please resolve the merge conflicts.