Messages in this thread | | | Date | Mon, 20 Feb 2006 16:36:07 +0100 | From | Herbert Poetzl <> | Subject | Re: (pspace,pid) vs true pid virtualization |
| |
On Mon, Feb 20, 2006 at 05:44:47PM +0300, Kirill Korotaev wrote: >> >fine, agreed on this finally, same for OpenVZ. >> hey we have soemthing :) > :)
>>>> definitely, we (Linux-VServer) added this some time ago >>>> and it helps to maintain/restart a guest.
>>> but why sys_waitpid? we can make it in many other ways,
>> yes, we currently have a syscall switch command >> to wait for the guest, but, of course, it is >> very similar to the 'normal' unix waitpid()
> this is more logically clean to me, since containers/namespaces are > not tasks. If someone wants to use more unix-like semantics, he can > obtain fd for namespace and call select/poll on it :))))
well, I'm neither for nor against a separate syscall here, don't get me wrong, but it will take ages to get the 'new' syscalls added to all archs, and the arch maintainers will probably have a dozent reasons why this particular syscall is completely wrong :)
>>> And we had issues in OpenVZ, that very fast VPS stop/start can fail >>> due to not freed resources yet.
>> this is a design problem, if your design allows >> to have _more_ than one pid space with the same >> identifier/properties, but with only one active >> and thus reachable space, it is no problem to >> create a new one right after the old one did send >> the event (which doesn't mean that it was destroyed >> just that the last process left the space)
> see my another email about sockets.
which one?
[ some context lost here ]
>>> How about third party apps?
>> I don't think we care about third party apps when >> adding new kernel functionality, especially not >> proprietary ones which cannot be modified easily
> Even if we don't take into account proprietary apps, there too many > opensource control panels, management tools etc. So this doesn't look > good to me anyhow.
well, they would see exactly the same as before, not more and not less, new features will require new tools and/or adaptations to the old ones. period.
>>> agreed. Though I don't like a backdoor name :) >>> It is just a way to get access to VPS.
>> well, it is often a way to get access to the VPS >> without the 'owner' of that VPS even knowing, so >> IMHO it's a backdoor, access would be via sshd or >> console :)
> When you have a physical box there are many ways to get access to it > without knowing passwords etc. This is the same.
does that change what it is, a backdoor circumventing established security? I don't think so ...
best, Herbert
> Kirill - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |