[CRIU] How can I get "real pid" in pid namespace?

[Pavel Emelyanov]

On 07/01/2013 11:19 AM, Chanho Park wrote:
>> I think your need is "Other processes can identify the process from pid",
>> and "convert vpid to pid" is one solution you figured out, right?
>>
>> So here I offer another solution to satisfy the needs, since we have
>> this function in kernel:
> 
> I know we can get vpid and pid and pidns and any other things in the kernel
> level.
> I mean, "Does it possible in the user level?"

Currently -- no.

> To export vpid and pidns, we should implement more things in the kernel
> layer.

I believe this should not be done. Otherwise this would break the whole
pid namespaces idea.

>>
>> struct task_struct *find_task_by_vpid(pid_t vnr) {
>> 	return find_task_by_pid_ns(vnr, current->nsproxy->pid_ns); }
>>
>> struct task_struct *find_task_by_pid_ns(pid_t nr, struct pid_namespace
>> *ns) {
>> 	rcu_lockdep_assert(rcu_read_lock_held(),
>> 			   "find_task_by_pid_ns() needs rcu_read_lock()"
>> 			   " protection");
>> 	return pid_task(find_pid_ns(nr, ns), PIDTYPE_PID); }
>>
>> In your condition, you can't get pid_ns through current, so I suggest
>> you export pid_ns *and* vpid, so you can get that task_struct.
>>
>>>
>>>>
>>>>>
>>>>> I know the behavior is not suitable for the purpose of container.
>>>>> I think if the virtual pid is exported to out of namespace, it
>>>>> should be converted to the real pid.
>>>>>
>>>>> How can the process get "real pid" in the pid namespace?
>>>>
>>>> It can't, the process in the pid namespace can't know they are in a
>>>> sub pidns or not, the mechanism decide this.
>>>
>>> Do we need new API like export_pid() to get the real pid in the pid
>>> namespace?
>>
>> I don't think so, like I said, get the real pid in the pid namespace
>> will break the design.
> 
> I think it looks like blue pill and red pill in the Matrix movie.
> To exit from the container, we should eat the red pill :)
> 
> Return to CRIU, if we don't use pid namespace, dumped pid will be not
> changed.
> If a machine already use the pid, we can't restore the state.

Yes.

> To avoid this problem, we should use the namespace features.

Exactly.

> However, if we use the pid namespace, we can't support the behavior which
> communicates pid information out of the container.

If you somehow leak any ID outside of what you dump with CRIU you
risk to break things in any case.

> Best Regards,
> Chanho Park
> 
> .
>