Re: [PATCH 0/2] namespaces: log namespaces per task
From: Nicolas Dichtel
Date: Tue May 06 2014 - 08:35:18 EST
Le 06/05/2014 01:23, James Bottomley a écrit :
On May 5, 2014 3:36:38 PM PDT, Serge Hallyn <serge.hallyn@xxxxxxxxxx> wrote:
Quoting James Bottomley (James.Bottomley@xxxxxxxxxxxxxxxxxxxxx):
On Mon, 2014-05-05 at 22:27 +0000, Serge Hallyn wrote:
Quoting James Bottomley (James.Bottomley@xxxxxxxxxxxxxxxxxxxxx):
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@xxxxxxxxxxxxxxxxxxxxx):
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.
We're looking ahead to a time when audit is namespaced, and a
container
can keep its own audit logs (without limiting what the host audits
of
course). So if a container is auditing suspicious activity by some
task in a sub-namesapce, then the whole parent container gets
migrated,
after migration we want to continue being able to correlate the
namespaces.
We're also looking at audit trails on a host that is up for years.
We
would like every namespace to be uniquely logged there. That is
why
inode #s on /proc/self/ns/* are not sufficient, unless we add a
generation
# (which would end more complicated, not less, than a serial #).
Right, but when the contaner has an audit namespace, that namespace
has
a name,
What ns has a name?
The netns for instance.
netns does not have names. iproute2 uses names (a filename in fact, to hold a
reference on the netns), but the kernel never got this name. It only get a file
descriptor (or a pid).
Regards,
Nicolas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/