Re: [RFC 1/3] userns: add uuid field

["Serge E. Hallyn" <serge@hallyn.com>]

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?

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

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

-serge