Virtualizing /proc/sys/kernel/random/boot_id per container ?
Eric W. Biederman
ebiederm at xmission.com
Tue Sep 4 09:20:46 UTC 2012
Glauber Costa <glommer at parallels.com> writes:
>> The twist of course is what does a boot mean. If we are really after
>> machine boots than the current behavior is correct.
>>
>> Looking back in the archives the desired behavior appears to be a value
>> that can be used to see if a pid value must be stale.
>>
>> As a stale pid detector boot_id is pretty lousy. Pids can still be
>> reused.
>>
>> Still a role as a stale pid detector makes it clear which namespace
>> boot_id should be in and how we should treat boot_id upon migration.
>>
>> You can only serve as a stale pid detector if you are in the pid
>> namespace.
>>
>> So at this point patches are welcome. Hopefully with a summary
>> of the discussion.
>>
>> Eric
>>
>
> Your discussion about boot_id being a limited solution is totally valid.
> But it is orthogonal to the question of whether or not a container
> should have it.
The important part is that boot_id as originally conceived is an
identifier to be used in conjunction with pids. Therefore boot_id is a
proper pid_namespace component, and there are no semantic problems with
putting it in the kernel.
> I took a look at this, and I think the kernel should be in perfect
> position to do it.
Agreed.
> boot_id as a pid namespace id is a very well defined concept.
Agreed.
A reference to the history and the definition needs to be in the patch
description.
> We just
> need an interface to set it up to make it stable across migration. Maybe
> we can accept writes to this file as valid, provided the pid namespace
> has only the init process.
I think the easy solution is to take advantage of the fact that boot_id
is initialized lazily. Don't allow writes if boot_id has already been
read.
> Then any tool could clone, mount proc, set this id, and continue
> normally. Any objections ?
My biggest concern is that creating multiple pid namespaces might allow
a way to drain the entropy pool in a way that we don't allow normal
users.
This is important to look at as with a little luck we will have
unprivileged creation of user namespaces and pid namespaces in the near
future.
Eric
More information about the Containers
mailing list