Quoting Eric W. Biederman (ebiederm@xxxxxxxxxxxx): > Sukadev Bhattiprolu <sukadev@xxxxxxxxxxxxxxxxxx> writes: > > > Eric W. Biederman [ebiederm@xxxxxxxxxxxx] wrote: > > | > > | I think replacing a struct pid for another struct pid allocated in > > | descendant pid_namespace (but has all of the same struct upid values > > | as the first struct pid) is a disastrous idea. It destroys the > > > > True. Sorry, I did not mean we would need a new 'struct pid' for an > > existing process. I think we talked earlier of finding a way of attaching > > additional pid numbers to the same struct pid. > > I just played with this and if you make the semantics of unshare(CLONE_NEWPID) > to be that you become the idle task aka pid 0, and not the init task pid 1 the > implementation is trivial. Heh, and then (browsing through your copy_process() patch hunks) the next forked task becomes the child reaper for the new pidns? <shrug> why not I guess. Now if that child reaper then gets killed, will the idle task get killed too? And if not, then idle task can just re-populating the new pidns with new idle tasks... If this brought us a step closer to entering an existing pidns that would be one thing, but is there actually any advantage to being able to unshare a new pidns? Oh, I guess there is - PAM can then use it at login, which might be neat. -serge -- 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
