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

On May 5, 2014 3:36:38 PM PDT, Serge Hallyn <serge.hallyn(a)ubuntu.com&gt; wrote: > Quoting James Bottomley (James.Bottomley(a)HansenPartnership.com): >> On Mon, 2014-05-05 at 22:27 +0000, Serge Hallyn wrote: >>> Quoting James Bottomley (James.Bottomley(a)HansenPartnership.com): >>>> 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(a)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. >>> >>> 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.