[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160413190152.GA29753@mail.hallyn.com>
Date: Wed, 13 Apr 2016 14:01:52 -0500
From: "Serge E. Hallyn" <serge@...lyn.com>
To: Tejun Heo <tj@...nel.org>
Cc: "Serge E. Hallyn" <serge@...lyn.com>, linux-api@...r.kernel.org,
adityakali@...gle.com,
Linux Containers <containers@...ts.osdl.org>,
"Eric W. Biederman" <ebiederm@...ssion.com>,
cgroups@...r.kernel.org, lkml <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH] cgroup namespaces: add a 'nsroot=' mountinfo field
Quoting Tejun Heo (tj@...nel.org):
> Hello, Serge.
>
> On Wed, Apr 13, 2016 at 01:46:39PM -0500, Serge E. Hallyn wrote:
> > It's not a leak of any information we're trying to hide. I realize
> > something like 8 years have passed, but I still basically go by the
> > ksummit guidance that containers are ok but the kernel's first priority
> > is to facilitate containers but not trick containers into thinking
> > they're not containerized. So long as the container is properly set
> > up, I don't think there's anything the workload could do with the
> > nsroot= info other than *know* that it is in a ns cgroup.
> >
> > If we did change that guidance, there's a slew of proc info that we
> > could better virtualize :)
>
> I see. I'm just wondering because the information here seems a bit
> gratuituous. Isn't the only thing necessary telling whether the root
> is bind mounted or namescoped? Wouldn't simple "nsroot" work for that
> purpose?
I don't think so - we could be in a cgroup namespace but still have
access only to bind-mounted cgroups. So we need to compare the
superblock dentry root field to the nsroot= value.
Powered by blists - more mailing lists