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

[Christian Brauner <christian.brauner@ubuntu.com>]

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