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 doesn't have to be random (some of the versions are time or other unique object based properties) but it does have to be derived by something that gives reasonably reliable uniqueness (which is why humans aren't allowed to set them ... we're bad a choosing unique labels). > > settable and a monotonic counter sounds like it shouldn't? Because > > to me (coming I suppose from dealing with uuids in edk2) neither > > sounds like it should be settable. > > Huh - yes, in contrast, for virtualization based tests of secureboot > and fs-y things we do indeed always set the uuids. Well, the old msdos label had a settable ID that often caused problems because it wasn't unique. The new gpt partition label specifically doesn't allow you to set the GUID label because it should be unique: https://en.wikipedia.org/wiki/GUID_Partition_Table I think some of the tools have emergency modes where you can set the label "just in case" but they shouldn't The point is that if you're using a settable uuid for containers, you're doing the wrong thing ... it should either be a non-unique label (in which case why not make it more human readable) or only the system should be allowed to set it using the prescribed algorithm. James
