On 11/29/21 08:56, Christian Brauner wrote:
On Mon, Nov 29, 2021 at 08:49:40AM -0500, Stefan Berger wrote:
On 11/28/21 20:59, Serge E. Hallyn wrote:
On Sun, Nov 28, 2021 at 05:56:28PM -0500, James Bottomley wrote:
On Sun, 2021-11-28 at 15:49 -0600, Serge E. Hallyn wrote:
On Sun, Nov 28, 2021 at 04:21:29PM -0500, James Bottomley wrote:
On Sun, 2021-11-28 at 14:47 -0600, Serge E. Hallyn wrote:
On Sun, Nov 28, 2021 at 01:00:28PM -0500, James Bottomley wrote:
On Sun, 2021-11-28 at 09:18 -0600, Serge E. Hallyn wrote:
[...]
So given that 'unique per boot' is sufficient, what would be
the problem with simply adding a simple ever-increasing
unique atomix count to the struct user_namespace?
I don't think there is any ... but I equally don't see why
people would want to save and restore the uuid but not the new
monotonic identifier ... because it's still just a marker on a
namespace.
But you've called it "the namespace uuid". I'm not even really
thinking of checkpoint/restart, just stopping and restarting a
container. I'm convinced people will want to start using it
because, well, it is a nice feature.
Right, but the uniqueness property depends on you not being able to
set it. If you just want a namespace label, you can have that, but
anything a user can set is either a pain to guarantee uniqueness
(have to check all the other objects) or is simply a non-unique
label.
If you want to label a container, which could have many namespaces
and be stopped and restarted many times, it does sound like you
want a non-unique settable label. However, IMA definitely needs a
guaranteed per namespace unique label.
Is the objection simply you think a UUID sound like it should be
Objection is too strong. Concern.
But yes, to me a uuid (a) feels like it should be generally useful
including being settable and (b) not super duper 100% absolutely
guaranteed to always be unique per boot, as an incremented counter
would be.
OK, but a bunch of cats I found on the Internet agree with me, a UUID
shouldn't be settable:
https://en.wikipedia.org/wiki/Universally_unique_identifier
The key point being, if you can set the id, it can't be unique ... it
Ok, so can you just put a comment above there saying "this must not
be settable from userspace" ?
So I have been working on an IMA namespacing series again as well and would
like to use some sort of unique identifier for audit messages emitted from
an IMA/user namespace other than the init_ima_ns. This UUID may just work
for this, but how would one associate the UUID with a container if it ever
comes to that when evaluating audit logs? Shouldn't it be settable from user
space for some sort of 'coordination' between container runtime and kernel?
Wouldn't this be solved by the audit container id patchset? In fact,
can't we use this for IMA as well?
I suppose it's this yet-to-be-merged series you are referring to:
https://lkml.org/lkml/2021/1/12/818
It would work for as long as it's *required* to set the identifier or
the identifier is readily available when the first audit message needs
to be emitted. If this is not the case then that unique identifier
should maybe originate in the kernel and be queryable by user space but
then again the same container may come up with different identifiers
every time. I am not sure whether that is desirable. Some sort of 'base
UUID' could be passed with the clone3() call and either all namespaces
could derive from the base UUID or just get the same value. If that's
not set the kernel gets to choose the base UUID... At least by updating
container runtimes the coordination issue could be solved and with the
clone3() call the early availability of the UUID could be guranteed?
