Quoting Aditya Kali (adityak...@google.com):
> On Wed, Apr 13, 2016 at 12:01 PM, Serge E. Hallyn wrote:
> > Quoting Tejun Heo (t...@kernel.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 h
On Wed, Apr 13, 2016 at 12:01 PM, Serge E. Hallyn wrote:
> Quoting Tejun Heo (t...@kernel.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,
Hello,
On Wed, Apr 13, 2016 at 02:01:52PM -0500, Serge E. Hallyn wrote:
> 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.
I see. No objection then.
Thanks.
Quoting Tejun Heo (t...@kernel.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 contai
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
Quoting Tejun Heo (t...@kernel.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
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
Hello, Serge.
On Mon, Mar 28, 2016 at 08:12:03PM -0500, Serge E. Hallyn wrote:
> Quoting Serge E. Hallyn (se...@hallyn.com):
> > One practical problem I've found with cgroup namespaces is that there
> > is no way to disambiguate between a cgroupfs mount which was done in
> > a cgroup namespace, an
Quoting Tycho Andersen (tycho.ander...@canonical.com):
> Hi Serge,
>
> On Mon, Mar 21, 2016 at 06:41:33PM -0500, Serge E. Hallyn wrote:
> > One practical problem I've found with cgroup namespaces is that there
> > is no way to disambiguate between a cgroupfs mount which was done in
> > a cgroup na
Hi Serge,
On Mon, Mar 21, 2016 at 06:41:33PM -0500, Serge E. Hallyn wrote:
> One practical problem I've found with cgroup namespaces is that there
> is no way to disambiguate between a cgroupfs mount which was done in
> a cgroup namespace, and a bind mount of a cgroupfs directory. So
> whether I
Quoting Serge E. Hallyn (se...@hallyn.com):
> One practical problem I've found with cgroup namespaces is that there
> is no way to disambiguate between a cgroupfs mount which was done in
> a cgroup namespace, and a bind mount of a cgroupfs directory. So
> whether I do
>
> unshare --cgroup -- bash
11 matches
Mail list logo
