Re: [PATCHv3 2/2] /proc/PID/status: show all sets of pid according to ns

[Serge E. Hallyn]

Quoting Chen, Hanxiao (chenhanxiao@xxxxxxxxxxxxxx):
> Hi,
> 
> > -----Original Message-----
> > From: Serge E. Hallyn [mailto:serge@xxxxxxxxxx]
> > Sent: Monday, September 29, 2014 10:00 PM
> > Subject: Re: [PATCHv3 2/2] /proc/PID/status: show all sets of pid according to
> > ns
> [snip]
> > > >
> > > > This patch adds four fields: NStgid, NSpid, NSpgid and NSsid:
> > > > a) In init_pid_ns, nothing changed;
> > > >
> > > > b) In one pidns, will tell the pid inside containers:
> > > > NStgid:	21776   5       1
> > > > NSpid:  21776   5       1
> > > > NSpgid:	21776   5       1
> > > > NSsid:  21729   1       0
> > > > ** Process id is 21776 in level 0, 5 in level 1, 1 in level 2.
> > > >
> > > > c) If pidns is nested, it depends on which pidns are you in.
> > > > NStgid: 5       1
> > > > NSpid:  5       1
> > > > NSpgid: 5       1
> > > > NSsid:  1       0
> > > > ** Views from level 1
> > > >
> > >
> > > This patch is simple, useful and safe.
> > > But currently there is not any feedbacks.
> > >
> > > Any comments or ideas?
> > 
> > Thanks, Chen.  The code looks fine.  My concern is that you are
> > exposing information which cannot be checkpointed and restarted.
> > In particular, if I'm inside a nested container, so I'm in pidns
> > level 3, then my own NSpid info, when I read it, will show the
> > pids at parent namespaces.  If I'm restarted at the third pidns
> > level, only the one pid can be restored.
> 
> If you're in level 3, read your own proc, only level 3's NSpid info
> will be shown. No parent namesapces info could be seen.

D'oh!  Sorry, I see, you're starting at ns->level.  And ns is the ns
of the proc mount, not the caller.  that looks good.

So

Acked-by: Serge Hallyn <serge.hallyn@xxxxxxxxxxxxx>

> Only if not providing a procfs mount point for the new container,
> and without a proper pivot_root,
> we could see some NSpid info of parent ns.
> 
> If each new container got their own procfs mount point,
> only its and its child's NSpid info could be seen.
> 
> > 
> > Now it may be fair to say "this is proc, and proc and sys show
> > host info which is not containerized and cannot be checkpointed
> > and restarted, deal with it."  But I'm not sure.
> > 
> > There are two ways you could deal with this.  One would be to
> > show the nspids only to the level of the reader of the file - but
> > I don't think you need to do that.  I think you're better off
> > simply showing the pids up to the level of the struct pid for
> > the mounter of the procfs.  So if I'm inside container c2 which
> > is inside container c1, my own /proc will only show pids which
> > are valid in c2 (and any child namespaces), while the /proc
> > mounted in c1 will show pids valid in c1 and c2 (and any children),
> > but not those in the init_pid_ns.  It's then just up to the
> > container administrators to make sure that c2 cannot see c1's
> > /proc to confuse itself and confuddle checkpoint-restart
> 
> IIUC, this patch already deal with this scenario:
> 
> +	for (g = ns->level; g <= pid->level; g++)
> +		seq_printf(m, "\t%d ",
> +			task_tgid_nr_ns(p, pid->numbers[g].ns));
> 
> With this patch, it did like
> a) in init_pid_ns, check /proc/21776/status
> NStgid:	21776   5       1
> 
> b) in c1, check /proc/5/status:
> NStgid:	5       1
> 
> c) in c2, check /proc/1/status:
> NStgid:	1
> 
> Thanks,
> - Chen
--
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/