Messages in this thread |  | | | Date | Thu, 17 Nov 2011 16:49:36 +0100 | | From | Oleg Nesterov <> | | Subject | Re: [RFC][PATCH 0/3] fork: Add the ability to create tasks with given pids |
| |
On 11/17, Pavel Emelyanov wrote: > > Gentlemen, please, find some time for this, your ACK/NACK on the API proposal > is required badly.
Please.
> The proposal is to introduce the CLONE_CHILD_USEPIDS flag for clone() syscall > and pass the pids values in the child_tidptr. In order not to introduce the > hole for the pid-reuse attack, using this flag will result in EPERM in case > the pid namespace we're trying to create pid in has at least one pid (except > for the init's one) generated with regular fork()/clone(). > > Currently Tejun and Oleg are worrying only about the intrusiveness of this > approach, although Oleg agrees, that it solves all the problems it should. The > previous attempts to implement the similar stuff stopped, but no objections > against this were expressed. So the decision of whether it's OK to go this > way or not is required.
Yes, personally I'd prefer /proc/set_last_pid (or something similar) which simply writes to pid_ns->last_pid. Perhaps it is less convenient from the user-space pov (serialization, security) but it is much simpler.
OTOH, I do not pretend I understand the user-space needs, so I won't argue. This series seems correct, the bugs we discussed are fixed.
But. Speaking of API, it differs a bit compared to the previous version...
> The API will be used like in the code below > > /* restore new pid namespace with an init in it */ > pid = clone(CLONE_NEWPID);
Yes, CLONE_NEWPID | CLONE_CHILD_USEPIDS is not possible. Then how the array of pids in child_tidptr[] can be useful? If CLONE_NEWPID can't restore the pid_nr's in the parent namespaces, then probably this doesn't makes sense at all?
IOW. I think we should either allow CLONE_NEWPID | CLONE_CHILD_USEPIDS (with additional check in set_pidmap() to ensure that CLONE_NEWPID comes with child_tidptr[0] == 1), or we should treat the "overloaded" child_tidptr as a simple pid_t. Again, I won't insist. Just I want to be sure we do not miss something adding the new API.
Oleg.
|  |