Messages in this thread | | | Date | Sun, 13 Nov 2011 20:28:48 +0100 | From | Oleg Nesterov <> | Subject | Re: [PATCH 3/3] pids: Make it possible to clone tasks with given pids |
| |
On 11/11, Pavel Emelyanov wrote: > > Hm, so intrusiveness is your main concern here, I see.
To me, this is important.
> OK, let's assume we go with sysctl setting the last_pid. > > One of the major concerns with previous attempts have been - someone creates > a process with a pid that was in use by some app recently and screws things > up with pid reuse.
Good point.
> My approach solves this,
Yes. Although, can't resist, in a subtle way (imho). CLONE_CHILD_USEPIDS stops working after a clone() without this flag.
> how can sysctl handle it? Allowing > the last_pid change by the CAP_SYA_ADMIN
Yes, when I suggested set_last_pid I assumed that it needs CAP_SYS_ADMIN.
> only is not an option, since people > are looking forward to non-root restore.
But CLONE_NEWPID needs CAP_SYS_ADMIN too ?
Anyway, I do not pretend I understand the problem space. And probably it would be more convenient to change the creds before forking some children with the predefined pids, I do not know.
So yes, I agree, CLONE_CHILD_USEPIDS wins here. Perhaps set_last_pid needs another sysctl(set_last_pid_allowed)/whatever, or another idea. Or we should use CLONE_CHILD_USEPIDS ;)
Let me repeat. It is not that I strongly against CLONE_CHILD_USEPIDS (although yes, I can't say personally I like it very much ;). Just I am trying to ensure we can't make something more clear/clean/simple, at least from the kernel pov. Especially because you are trying to establish the new user-visible API.
Oleg.
| |