From: Serge Hallyn <serge.hallyn@ubuntu.com>
To: Richard Guy Briggs <rgb@redhat.com>
Cc: James Bottomley <James.Bottomley@HansenPartnership.com>,
containers@lists.linux-foundation.org,
linux-kernel@vger.kernel.org, eparis@redhat.com,
linux-audit@redhat.com, ebiederm@xmission.com, sgrubb@redhat.com
Subject: Re: [PATCH 0/2] namespaces: log namespaces per task
Date: Tue, 6 May 2014 03:33:08 +0000 [thread overview]
Message-ID: <20140506033308.GE6508@ubuntumail> (raw)
In-Reply-To: <20140505214424.GB6867@madcap2.tricolour.ca>
Quoting Richard Guy Briggs (rgb@redhat.com):
> On 14/05/03, James Bottomley wrote:
> > 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.
>
> I hadn't thought to distinguish a migrated container from an unmigrated
> one, but rather I'm more interested in the underlying namespaces. The
> use of a generation number to identify a migrated namespace may be
> useful along with the logging to tie them together.
>
> > 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?
>
> The original intent was to track the underlying namespaces themselves.
> This sounds like another layer on top of that which sounds useful but
> that I had not yet considered.
>
> But yes, that sounds like a good eventual goal.
Right and we don't need that now, all *I* wanted to convince myself of
was that a serial # as you were using it was not going to be a roadlbock
to that, since once we introduce a serial #, we're stuck with that as
user-space facing api.
> > 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,
> > if you look at all the management systems for containers, they all have
> > a concept of some unique ID per container, be it name, UUID or even
> > GUID. I suspect it's that you should be using to tag the audit trail
> > with.
>
> That does sound potentially useful but for the fact that several
> containers could share one or more types of namespaces.
>
> Would logging just a container ID be sufficient for audit purposes? I'm
> going to have to dig a bit to understand that one because I was unaware
> each container had a unique ID.
They don't :)
> I did originally consider a UUID/GUID for namespaces.
So I think that apart from resending to address the serial # overflow
comment, I'm happy to ack the patches. Then we probably need to convicne
Eric that we're not torturing kittens.
-serge
next prev parent reply other threads:[~2014-05-06 3:33 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-22 18:12 [PATCH 0/2] namespaces: log namespaces per task Richard Guy Briggs
2014-04-22 18:12 ` [PATCH 1/2] namespaces: give each namespace a serial number Richard Guy Briggs
2014-05-01 22:51 ` Serge E. Hallyn
2014-05-02 14:15 ` Richard Guy Briggs
2014-05-02 20:50 ` Serge Hallyn
2014-04-22 18:12 ` [PATCH 2/2] audit: log namespace serial numbers Richard Guy Briggs
2014-05-01 23:01 ` Serge E. Hallyn
2014-05-01 22:32 ` [PATCH 0/2] namespaces: log namespaces per task Serge E. Hallyn
2014-05-02 14:28 ` Richard Guy Briggs
2014-05-02 21:00 ` Serge Hallyn
2014-05-05 21:29 ` Richard Guy Briggs
2014-05-05 9:23 ` Nicolas Dichtel
2014-05-06 21:15 ` Richard Guy Briggs
2014-05-07 9:35 ` Nicolas Dichtel
2014-05-03 21:58 ` James Bottomley
2014-05-05 3:48 ` Serge E. Hallyn
2014-05-05 21:48 ` Richard Guy Briggs
2014-05-05 21:51 ` James Bottomley
2014-05-05 22:11 ` Richard Guy Briggs
2014-05-05 22:24 ` James Bottomley
2014-05-05 22:27 ` Serge Hallyn
2014-05-05 22:30 ` James Bottomley
2014-05-05 22:36 ` Serge Hallyn
2014-05-05 23:23 ` James Bottomley
2014-05-06 3:27 ` Serge Hallyn
2014-05-06 4:59 ` James Bottomley
2014-05-06 14:50 ` Serge Hallyn
2014-05-06 21:59 ` Richard Guy Briggs
2014-05-06 12:35 ` Nicolas Dichtel
2014-05-06 21:41 ` Richard Guy Briggs
2014-05-06 23:57 ` James Bottomley
2014-05-05 21:44 ` Richard Guy Briggs
2014-05-06 3:33 ` Serge Hallyn [this message]
2014-05-06 14:03 ` Richard Guy Briggs
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140506033308.GE6508@ubuntumail \
--to=serge.hallyn@ubuntu.com \
--cc=James.Bottomley@HansenPartnership.com \
--cc=containers@lists.linux-foundation.org \
--cc=ebiederm@xmission.com \
--cc=eparis@redhat.com \
--cc=linux-audit@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rgb@redhat.com \
--cc=sgrubb@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox