[PATCH 0/2] namespaces: log namespaces per task

[James Bottomley]

On Mon, 2014-05-05 at 18:11 -0400, Richard Guy Briggs wrote:
> On 14/05/05, James Bottomley wrote:
> > On Mon, 2014-05-05 at 17:48 -0400, Richard Guy Briggs wrote:
> > > On 14/05/05, Serge E. Hallyn wrote:
> > > > Quoting James Bottomley (James.Bottomley at HansenPartnership.com):
> > > > > On Tue, 2014-04-22 at 14:12 -0400, Richard Guy Briggs wrote:
> > > > > > Questions:
> > > > > > Is there a way to link serial numbers of namespaces involved in migration of a
> > > > > > container to another kernel?  (I had a brief look at CRIU.)  Is there a unique
> > > > > > identifier for each running instance of a kernel?  Or at least some identifier
> > > > > > within the container migration realm?
> > > > > 
> > > > > Are you asking for a way of distinguishing an migrated container from an
> > > > > unmigrated one?  The answer is pretty much "no" because the job of
> > > > > migration is to restore to the same state as much as possible.
> > > > > 
> > > > > Reading between the lines, I think your goal is to correlate audit
> > > > > information across a container migration, right?  Ideally the management
> > > > > system should be able to cough up an audit trail for a container
> > > > > wherever it's running and however many times it's been migrated?
> > > > > 
> > > > > In that case, I think your idea of a numeric serial number in a dense
> > > > > range is wrong.  Because the range is dense you're obviously never going
> > > > > to be able to use the same serial number across a migration.  However,
> > > > 
> > > > Ah, but I was being silly before, we can actually address this pretty
> > > > simply.  If we just (for instance) add
> > > > /proc/self/ns/{ic,mnt,net,pid,user,uts}_seq containing the serial number
> > > > for the relevant ns for the task, then criu can dump this info at
> > > > checkpoint.  Then at restart it can dump an audit message per task and
> > > > ns saying old_serial=%x,new_serial=%x.  That way the audit log reader
> > > > can if it cares keep track.
> > > 
> > > This is the sort of idea I had in mind...
> > 
> > OK, but I don't understand then why you need a serial number.  There are
> > plenty of things we preserve across a migration, like namespace name for
> > instance.  Could you explain what function it performs because I think I
> > might be missing something.
> 
> If a container was defined as an entity with 6 namespaces to itself,
> this would make sense.  As Eric P. put it, containers/namespaces seem to
> be a bucket of semi-related nuts and bolts, with any namespace being
> optional depending on the application.

That's right.  An IaaS container has a well defined composition, since
it has to contain a full OS, but an application container is variable.

It's the usual procedure with container management systems to have one
name for the container and give this name to all the namespaces, but I
agree, it doesn't have to.

>   My understanding is a
> container could be migrated to another host requiring the creation of
> (none,) some or all of its namespaces, potentially leaving behind some
> of its shared namespaces and/or clashing names of namespaces on the
> destination host.

Well, no, the environment gets migrated as well so when the migration is
over, the namespaces the migrated entity is in will look the same as
before the migration ... if they didn't exist on the recipient, they'll
be created.  If a namespace already exists the restore fails ... this is
because we support the usual container case where you're migrating to a
disjoint set of namespaces.

Even if there were some reason for supporting shared namespaces, the
fundamental invariant is still the namespace names (i.e. the namespaces
have the same names before and after migration), so how does a serial
number help?

James

> > James
> > 
> > > > -serge
> > > > 
> > > > (Another, more heavyweight approach would be to track all ns hierarchies
> > > > and make the serial numbers per-namespace-instance.  So my container's
> > > > pidns serial might be 0x2, and if it clones a new pidns that would be
> > > > "(0x2,0x1)" on the host, or just 0x1 inside the container.  But we don't
> > > > need that if the simple userspace approach suffices)
> > > 
> > > This sounds manageable...
> > > 
> > > - RGB
> > > 
> > > --
> > > Richard Guy Briggs <rbriggs at redhat.com>
> > > Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red Hat
> > > Remote, Ottawa, Canada
> > > Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545
> > 
> > 
> > 
> 
> - RGB
> 
> --
> Richard Guy Briggs <rbriggs at redhat.com>
> Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red Hat
> Remote, Ottawa, Canada
> Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545