Re: RFC [patch 13/34] PID Virtualization Define new task_pid api

[Eric W. Biederman]

Hubertus Franke <frankeh@xxxxxxxxxxxxxx> writes:

> In that case, I think we do require the current vpid_to_pid(translations)
> in order to transfer the external user pid ( relative to the namespace )
> into one that combines namespace (aka container_id) with the external pid.
> Exactly how it is done today.
> What will slightly change is the low level implementations of the
>
> inline pid_t pid_to_vpid_ctx(pid_t pid, const struct task_struct *ctx);
> pid_t __pid_to_vpid_ctx_excp(pid_t pid, int pidspace_id,const struct task_struct
> *ctx);
>
> and reverse.
> The VPID_2_PID and PID_2_VPID still remain at same locations.
>
> Did I get your comments correctly, Eric ?..

Well we may need that.   For the moment let's consider putting both
a kpid and upid and the task_struct, and elsewhere. Basically I don't think
translation is necessary in the common case.

However let's look at a single practical case to see how it would need
to be implemnted.

struct fown_struct.  Every file has one and you can modify it both on
a socket with ioctls FIOSETOWN,SIOCSPGRP,FIOGETOWN,SIOCPGRP.  And on
a normal file handle with fcntl with FSETOWN, and FGETOWN.

Since a struct file can be passed between processes in different
pid spaces using unix domain sockets we cannot count on the context
of the signaler to be the same as the context of the setter.

So we need to look at how to handle this case cleanly, and safely.

Eric

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/