I also don't understand why you are eager to introduce new sys calls
like pkill(path_to_process), but is trying to use waitpid() for pspace
die notifications? Maybe it is simply better to introduce container
specific syscalls which should be clean and tidy, instead of messing
things up with clone()/waitpid() and so on? The more simple code we
have, the better it is for all of us.
now that you mention it, maybe we should have a few
rounds how those 'generic' container syscalls would
look like?
I still like the following:
clone(): extended with flags for asking a private copy of various
namespaces. For the CLONE_NEWPIDSPACE flag, the pid which
is returned to the parent process is it's handle to the
new pidspace.
- clone has limited number of flags.
- sooner or later you will need to add flags about what and how you want
to close (e.g. pspace with weak or strong isolation and so on)
sys_execpid(pid, argv, envp): exec a new syscall with the requested
pid, if the pid is available. Else either return an error,
or pick a random pid. Error makes sense to me, but that's
probably debatable.
the problem is that in real life environments where executables can be
substitutes this is kind of a security issue. Also I really hate the
idea of using exec() for changing something.
In OpenVZ we successfully do context changes without exec()'s.
sys_fork_slide(pid): fork and slide into the pidspace belong to pid.
This way we can do things like
p = sys_fork_slide(2794);
if (p == 0) {
kill(2974);
} else {
waitpid(p, 0, 0);
}
Ok, this last one in particular needs to be improved, but these two
syscalls and the clone flags together give us all we need. Right?
Again, you concentrate on PIDspaces forgeting about all the other
namespaces.
I would prefer:
- sys_ns_create()
creates namespace and makes a task to inherit this namespace. If
_needed_, it _can_ fork inside.
- sys_ns_inherit()
change active namespace.
But how should we reference namespace? by globabl ID?
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]