On Mon, 2021-11-29 at 14:56 +0100, 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? Stefan asked, but it really doesn't have the properties we need, plus they don't seem to want the audit id used as the container id. How about this: Since the label has to be unique for the lifetime of the system, if we allow it to be settable, we'll have to carry it outside the namespace anyway because memory of the label has to live on after the namespace dies to avoid duplication, so I'll move it into a parallel namespace structure ima will carry. it will be settable once, but if you don't set it before it's used, then we'll set it to a randombly generated uuid. If you do set it, it will be checked for uniqueness against all previous labels. James
