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. > 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. > 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. James
