"Serge E. Hallyn" <serue@xxxxxxxxxx> writes: > 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? No. > And if not, then idle task can just re-populating the new pidns with new > idle tasks... After zap_pid_namespace interesting... > 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. I have to say that the semantics of my patch are unworkable for unshare. Unless I am mistaken for PAM to use it requires that the current process fully change and become what it needs to be. Requiring an extra fork to fully complete the process is a problem. Scratch one bright idea. 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
