[lxc-devel] Working with glibc (PID/TID caches).

[Eric W. Biederman]

Serge Hallyn <serge.hallyn at ubuntu.com> writes:
> Quoting Carlos O'Donell (carlos at redhat.com):
>> There was a complaint a while back from someone working
>> on containers about glibc PID caching. I recently received
>> another request to provide userspace with a way to reset
>> any PID or TID caches to make clone-based sandboxing easier
>> (CLONE_NEWPID).
>> 
>> How did lxc workaround the PID cache in glibc? What APIs
>> could glibc provide to help the implementation of containers?

The primary work-around was that neither unshare(CLONE_NEWPID)
nor clone(CLONE_NEWPID) changes the current processes pid,
so in practice cached pids are not much of a problem.

That said clone(3) is a cumbersome API to use when you don't want to
share the same address space (it sucks to have to allocate an extra
stack just to call fork(2)), and that probably gets people resorting to
calling syscall(SYS_clone,...) and then having pid problems.

> so this is (iiuc) only a problem with unshare(CLONE_NEWPID).  Two
> programs pasted below.  The one using unshare will show the old
> pre-unshare pid.  The one using clone correctly shows pid 1.  Now
> it's possible that clone() wrapper is doing something already to
> clean the pid, I didn't try syscall(__NR_CLONE) with CLONE_NEWPID
> today.  But I've seen quite a bit of code using clone(CLONE_NEWPID),
> and noone really uses the syscall directly any more.

Serge your unsharepid did not call fork(2) so there was no process placed
into the pid namespace.  So there was not a pid 1 yet.  I admit the
semantics of unshare(CLONE_NEWPID) are bizarre that way and seem to trip
everyone up.

The goal when designing them was to have something that could be used in
libpam during login so unshare could be called and the first process
created after that would be in the new pid namespace.  But I don't think
anyone has implemented that case yet. 

> AFAICT most ppl use clone, not unshare.  But so, perhaps glibc sholud
> have a unshare() wrapper which clears the pid cache?  Or glibc could
> export a function which callers would have to explicitly call.

Eric