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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
