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. 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 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? -serge
