Re: [RFC][PATCH 01/20] pid: Intoduce the concept of a wid (wait id)

[Kirill Korotaev <dev@sw.ru>]

>>2. Maybe I'm missing something in the discussions, but why is it required? if
>>you provide fully isolated pid spaces, why do you care for wid?
>>And how ptrace can work at all if cldstop reports some pid, but child is not
>>accessiable via ptrace()? and if it doesn't work, what are your changes for?
> 
> 
> A good question.
> 
> My pid spaces while isolated from each other are connected together in
> something that resembles the mount relationship when mounting a filesystem.
why? is it really required?
doing it this way, you get all the issues with external refs we have 
with a weak isolation, i.e. pspace init can be seen from outside and 
inside (correct? or am I wrong?). This makes your approach eseentially 
the same as ours from checkpointing point of view BTW.

> The init process of a child pspace is visible in the parent pspace,
> by it's wid.  So you should be able to ptrace pid == 1.  The other
> children remain inaccessible directly.
> 
> The idea was to do my very best to preserve the unix process tree when
> constructing a separate pid space
This more looks like you were trying to make less changes with it and 
avoid fixing issus which can arise when pspaces are fully isolated. 
Maybe I'm wrong.

> I have to admit I have not yet tested the ptrace corner case, or
> digested all of it's ramifications.  Unless I have messed up somewhere
> it should just work.
> 
> This visibility of the child tree by a single pid inside the parent
> tree is why I think my approach doesn't suffer from most of the
> problems a completely isolated pid space has.
which problems? Actually I can't see much problems with isolated pid 
spaces. And isolated pid spaces doesn't require hierarchy, since they 
are fully isolated.

> In fact I would even be willing to look at it as a global but
> hierarchical pid space if that proved an interesting case.
> So you could have something like pkill(int sig, int which, char *pid_path).
> Where pid_path is something like "1537/3/58", and which specified
> what kind of pid you are talking about (thread, pid, process group...)
And here you need to introduce new non-unix semantics, security checks 
on lookups, etc.

>>From a security stand point I want the option of a fully isolated
> group of processes, so there is a possibility of keeping secrets from
> the system administrator, but there is no reason that needs to be tied
> to a pid space.

Kirill