Pavel Emelyanov <xemul@xxxxxxxxxxxxx> writes: > Eric W. Biederman wrote: >> Pavel Emelyanov <xemul@xxxxxxxxxxxxx> writes: >> >>> Eric W. Biederman wrote: >>>> Pavel Emelyanov <xemul@xxxxxxxxxxxxx> writes: >>>> >>>>> Thanks. What's the problem with setns? >>>> joining a preexisting namespace is roughly the same problem as >>>> unsharing a namespace. We simply haven't figure out how to do it >>>> safely for the pid and the uid namespaces. >>> The pid may change after this for sure. What problems do you know >>> about it? What if we try to allocate the same PID in a new space >>> or return -EBUSY? This will be a good starting point. If we manage >>> to fix it later this will not break the API at all. >> >> Parentage. The pid is the identity of a process and all kinds of things >> make assumptions in all kinds of strange places. I don't see how >> waitpid can work if you change the pid. > > Agree. But what if we enter a pid space, which is a subnamespace of a current > one? In that case parent will still see the task by its old pid. We can restrict > first version of entering with this rule as well and this restriction will not > block us in typical usecase (I mean enter a container from a host). When I was thinking about pid namespaces and unshare last time. The idea I came to was we unshare of the pid namespace should only affect which pid namespace your children are in. I remember that do that there were a few cases where you would have to access task->pid->pid_ns instead of task->nsproxy->pid_ns, but essentially it was pretty simple. >> glibc doesn't cope if you change someones pid. > > OK, but what if we try to allocate the same pid returning -EBUSY on failure? > > My aim is to provide even a restricted enter. For most of the cases this > should work and make our lives easier. So two restrictions currently: > a) enter a sub namespace > b) allocate the same pid as we have now > > Hm? :) Replacing struct pid is guaranteed to do all kinds of nasty things with signal handling and the like, de_thread is nasty enough and you are talking something worse. So if we can change pid namespaces without changing the pid I am for it. Eric -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
