Re: (pspace,pid) vs true pid virtualization

[Herbert Poetzl]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/