On Sun, Nov 28, 2021 at 03:49:06PM -0600, Serge 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: > > > > > On Sun, Nov 28, 2021 at 08:29:21AM -0500, James Bottomley wrote: > > > > > > On Sat, 2021-11-27 at 22:45 -0600, Serge E. Hallyn wrote: > > > > > > > On Sat, Nov 27, 2021 at 04:45:47PM +0000, James Bottomley > > > > > > > wrote: > > > > > > > > As a precursor to namespacing IMA a way of uniquely > > > > > > > > identifying the namespace to appear in the IMA log is > > > > > > > > needed. This log may be transported away from the running > > > > > > > > system and may be analyzed even after the system has been > > > > > > > > rebooted. Thus we need a way of identifying namespaces in > > > > > > > > the log which is unique. UUID, being designed > > > > > > > > probabilistically never to repeat, fits this bill > > > > > > > > so add it to the user_namespace which we'll also use for > > > > > > > > namespacing IMA. > > > > > > > > > > > > > > If the logs run across 5 boots, is it important to you that > > > > > > > the uuid be unique across all 5 boots? Would it suffice to > > > > > > > have a per-boot unique count and report that plus some > > > > > > > indicator of the current boot (like boot time in jiffies)? > > > > > > > > > > > > For the purposes of IMA it's only really important to have the > > > > > > uuid be unique within the particular log ... i.e. unique per > > > > > > boot. However, given the prevalence of uuids elsewhere and the > > > > > > fact we have no current per-boot unique label for the namespace > > > > > > (the inode number could repeat), it seemed reasonable to employ > > > > > > uuids for this rather than invent a different identifier. Plus > > > > > > IMA isn't going to complain if we have a globally unique > > > > > > identifier > > > > > > ... > > > > > > > > > > Ok - Note I'm not saying I heavily object, but I'm mildly > > > > > concerned about users who happen to spin off a lot of user > > > > > namespaces for quick jobs being penalized. > > > > > > > > Well, that's why I use the uuid_gen coupled to prandom ... there > > > > shouldn't be a measurable overhead generating it. > > > > > > Does prandom have *no*, or just little effect on the entopy pool? > > > Tried briefly looking at prandom_u32, not quite getting how it's > > > using net_rand_state - it reads it and uses it but doesn't make > > > any changes to it? > > > > It has a first use effect to get the seed but once that happens it has > > no further effect on the entropy pool. > > Gotcha - thanks. > > > > > > I suspect Eric will also worry about the namespacing > > > > > implications - i.e. people *will* want to start restoring user > > > > > namespaces with a previously used uuid. > > > > > > > > So this is a problem I tried to address in the last paragraph. If > > > > I put any marker on a namespace, people are potentially going to > > > > want to save and restore it. The bottom line is that ima logs are > > > > add only. You can't save and restore them so we're already dealing > > > > with something that can't be CRIU transported. I had hoped that it > > > > would be obvious that a randomly generated uuid, whose uniqueness > > > > depends on random generation likewise can't be saved and restored > > > > because we'd have no way to prevent a clash. > > > > > > Yes but you're making this a general user_namespace struct member. > > > So once that's there people will want to export it, use it for > > > things other than ima. > > > > Yes, that's why I did it. However, the property of uniqueness for all > > uuid type things depends on randomness, so ipso facto, they can never > > be settable. > > > > > > > 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. I don't have strong feelings about uuid or counter. In something like an IMA log a uuid might be better but idk. I don't know enough about IMA to judge that. I see the problem you're getting at though. Making this a member of struct user_namespace will give the impression that is a generic identifier. I'd rather make it clear that this is an IMA-only thing. Ideally by not having it be a member of struct user_namespace at all or at least by naming it ima_uuid or similar. Christian
