linux-kernel - Re: [PATCHv3 8/8] cgroup: Add documentation for cgroup namespaces

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87twytklkv.fsf@x220.int.ebiederm.org>
Date:	Wed, 11 Feb 2015 00:29:20 -0600
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Tejun Heo <tj@...nel.org>
Cc:	"Serge E. Hallyn" <serge@...lyn.com>,
	Richard Weinberger <richard@....at>,
	Linux API <linux-api@...r.kernel.org>,
	Linux Containers <containers@...ts.linux-foundation.org>,
	Serge Hallyn <serge.hallyn@...ntu.com>,
	"linux-kernel\@vger.kernel.org" <linux-kernel@...r.kernel.org>,
	Andy Lutomirski <luto@...capital.net>,
	cgroups mailinglist <cgroups@...r.kernel.org>,
	Ingo Molnar <mingo@...hat.com>
Subject: Re: [PATCHv3 8/8] cgroup: Add documentation for cgroup namespaces

Tejun Heo <tj@...nel.org> writes:

> Hey,
>
> On Tue, Feb 10, 2015 at 11:02:40PM -0600, Eric W. Biederman wrote:
>> A slightly off topic comment, for where this thread has gone but
>> relevant if we are talking about cgroup namespaces.
>> 
>> If don't implement compatibility with existing userspace, they get a
>> nack.  A backwards-incompatible change should figure out how to remove
>> the need for any namespaces.
>>
>> Because that is what namespaces are about backwards compatibility.
>
> Are you claiming that namespaces are soley about backwards
> compatibility?  ie. to trick userland into scoping without letting it
> notice?  That's a very restricted view and namespaces do provide
> further isolation capabilties in addition to what can be achieved
> otherwise and it is logical to collect simliar funtionalities there.

In principle a namespace is an additional layer of indirection from
names to objects.  A namespace does not invent new kinds of objects.
A namespace takes things that were previously global and gives them a
scope.

In princple after name resolution a namespace should impose no overhead.

In general namespaces are not necessary if your scope of names
already has hierarchy.  Which means that new interfaces can almost
always be designed in such a way that you can support containers without
needing to add any special namespace support.  Which typically results
in more flexible and useful APIs for everyone, with no real code cost.

Further in the cgroup namespace patchset I looked at a while ago, the
only reason for having a cgroup namespace was to provide a measure of
backwards compatibility with existing userspace.  I expect removing the
/proc/<pid>/cgroup file and replacing it with something in cgroupfs
itself would serve just as well if backwards compatibility is not the
objective.  Or possibly replacincg /proc/<pid>/cgroup into a magic
symlink onto somewhere in the unified cgroupfs itself.

I just don't see any point in doing weird silly namespace things to keep
existing userspace working when the existing userspace won't work.

As such if a namespace doesn't implement compatibility with the existing
userspace it gets my nack.

Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/