From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754298AbaEEDsR (ORCPT ); Sun, 4 May 2014 23:48:17 -0400 Received: from static.92.5.9.176.clients.your-server.de ([176.9.5.92]:38128 "EHLO mail.hallyn.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752561AbaEEDsQ (ORCPT ); Sun, 4 May 2014 23:48:16 -0400 Date: Mon, 5 May 2014 05:48:14 +0200 From: "Serge E. Hallyn" To: James Bottomley Cc: Richard Guy Briggs , 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 Message-ID: <20140505034814.GA27548@mail.hallyn.com> References: <1399154328.2505.29.camel@dabdike.int.hansenpartnership.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1399154328.2505.29.camel@dabdike.int.hansenpartnership.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. -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)