[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160413184639.GA29483@mail.hallyn.com>
Date: Wed, 13 Apr 2016 13:46:39 -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.
>
> Sorry about the delay.
>
> On Mon, Mar 21, 2016 at 06:41:33PM -0500, Serge E. Hallyn wrote:
> > struct kernfs_syscall_ops {
> > int (*remount_fs)(struct kernfs_root *root, int *flags, char *data);
> > - int (*show_options)(struct seq_file *sf, struct kernfs_root *root);
> > + int (*show_options)(struct seq_file *sf, struct dentry *dentry,
> > + struct kernfs_root *root);
>
> Wouldn't it make more sense to pass in kernfs_node pointer instead of
> dentry pointer?
Yeah that definately seems better.
> > +static void cgroup_show_nsroot(struct seq_file *seq, struct dentry *dentry,
> > + struct kernfs_root *kf_root)
> > +{
> > + struct kernfs_node *d_kn = dentry->d_fsdata;
> > + char *nsroot;
> > + int len, ret;
> > +
> > + if (!kf_root)
> > + return;
> > + len = kernfs_path_from_node(d_kn, kf_root->kn, NULL, 0);
> > + if (len <= 0)
> > + return;
> > + nsroot = kzalloc(len + 1, GFP_ATOMIC);
> > + if (!nsroot)
> > + return;
> > + ret = kernfs_path_from_node(d_kn, kf_root->kn, nsroot, len + 1);
> > + if (ret <= 0 || ret > len)
> > + goto out;
>
> Hmmm.... does this mean that someone inside cgroup ns would be able to
> find out the absolute cgroup path of the ns root from inside? If so,
> wouldn't that be an unnecessary information leak?
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 :)
thanks,
-serge
Powered by blists - more mailing lists