All of lore.kernel.org
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Richard Guy Briggs <rgb@redhat.com>
Cc: "Serge E. Hallyn" <serge@hallyn.com>,
	linux-audit@redhat.com, linux-kernel@vger.kernel.org,
	containers@lists.linux-foundation.org, serge.hallyn@ubuntu.com,
	eparis@redhat.com, sgrubb@redhat.com, ebiederm@xmission.com
Subject: Re: [PATCH 0/2] namespaces: log namespaces per task
Date: Mon, 05 May 2014 14:51:38 -0700	[thread overview]
Message-ID: <1399326698.2164.47.camel@dabdike.int.hansenpartnership.com> (raw)
In-Reply-To: <20140505214818.GC6867@madcap2.tricolour.ca>

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

Thanks,

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




  reply	other threads:[~2014-05-05 21:51 UTC|newest]

Thread overview: 58+ 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 ` Richard Guy Briggs
     [not found] ` <cover.1398176489.git.rgb-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2014-04-22 18:12   ` [PATCH 1/2] namespaces: give each namespace a serial number Richard Guy Briggs
2014-04-22 18:12     ` Richard Guy Briggs
     [not found]     ` <be1358c6da51252cd79c51a51bb30bf157624ccd.1398176489.git.rgb-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2014-05-01 22:51       ` Serge E. Hallyn
2014-05-01 22:51         ` Serge E. Hallyn
     [not found]         ` <20140501225116.GB25669-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>
2014-05-02 14:15           ` Richard Guy Briggs
2014-05-02 14:15             ` Richard Guy Briggs
     [not found]             ` <20140502141530.GB24111-bcJWsdo4jJjeVoXN4CMphl7TgLCtbB0G@public.gmane.org>
2014-05-02 20:50               ` Serge Hallyn
2014-05-02 20:50                 ` Serge Hallyn
2014-04-22 18:12   ` [PATCH 2/2] audit: log namespace serial numbers Richard Guy Briggs
2014-04-22 18:12     ` Richard Guy Briggs
     [not found]     ` <644ef842bae19c55ae11af07e9fd7ac0ec9c74a1.1398176489.git.rgb-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2014-05-01 23:01       ` Serge E. Hallyn
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-01 22:32     ` Serge E. Hallyn
     [not found]     ` <20140501223212.GA25669-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>
2014-05-02 14:28       ` Richard Guy Briggs
2014-05-02 14:28         ` Richard Guy Briggs
     [not found]         ` <20140502142851.GC24111-bcJWsdo4jJjeVoXN4CMphl7TgLCtbB0G@public.gmane.org>
2014-05-02 21:00           ` Serge Hallyn
2014-05-02 21:00             ` Serge Hallyn
2014-05-05 21:29             ` Richard Guy Briggs
2014-05-05  9:23         ` Nicolas Dichtel
     [not found]           ` <5367587B.20801-pdR9zngts4EAvxtiuMwx3w@public.gmane.org>
2014-05-06 21:15             ` Richard Guy Briggs
2014-05-06 21:15               ` Richard Guy Briggs
     [not found]               ` <20140506211530.GB15100-bcJWsdo4jJjeVoXN4CMphl7TgLCtbB0G@public.gmane.org>
2014-05-07  9:35                 ` Nicolas Dichtel
2014-05-07  9:35                   ` Nicolas Dichtel
2014-05-03 21:58   ` James Bottomley
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 [this message]
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-05 23:23                   ` James Bottomley
2014-05-06  3:27                   ` Serge Hallyn
2014-05-06  3:27                     ` Serge Hallyn
2014-05-06  4:59                     ` James Bottomley
     [not found]                       ` <1399352350.2164.91.camel-sFMDBYUN5F8GjUHQrlYNx2Wm91YjaHnnhRte9Li2A+AAvxtiuMwx3w@public.gmane.org>
2014-05-06 14:50                         ` Serge Hallyn
2014-05-06 14:50                           ` Serge Hallyn
2014-05-06 21:59                         ` Richard Guy Briggs
2014-05-06 21:59                           ` Richard Guy Briggs
2014-05-06 12:35                   ` Nicolas Dichtel
2014-05-06 12:35                     ` Nicolas Dichtel
     [not found]                   ` <a09ed85b-d6ef-4472-853b-84057d5957c2-2ueSQiBKiTY7tOexoI0I+QC/G2K4zDHf@public.gmane.org>
2014-05-06 12:35                     ` Nicolas Dichtel
2014-05-06 21:41                     ` Richard Guy Briggs
2014-05-06 21:41                       ` Richard Guy Briggs
2014-05-06 21:41                       ` Richard Guy Briggs
     [not found]                       ` <20140506214129.GC15100-bcJWsdo4jJjeVoXN4CMphl7TgLCtbB0G@public.gmane.org>
2014-05-06 23:57                         ` James Bottomley
2014-05-06 23:57                           ` James Bottomley
2014-05-05 21:44     ` Richard Guy Briggs
2014-05-06  3:33       ` Serge Hallyn
2014-05-06 14:03         ` Richard Guy Briggs
2014-05-06 14:03         ` Richard Guy Briggs
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=1399326698.2164.47.camel@dabdike.int.hansenpartnership.com \
    --to=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=serge.hallyn@ubuntu.com \
    --cc=serge@hallyn.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.