netdev - Re: [RFC][PATCH] ns: Syscalls for better namespace sharing control.

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Sat, 27 Feb 2010 22:29:00 +0300
From:	Pavel Emelyanov <xemul@...allels.com>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
CC:	hadi@...erus.ca, Daniel Lezcano <dlezcano@...ibm.com>,
	Patrick McHardy <kaber@...sh.net>,
	Linux Netdev List <netdev@...r.kernel.org>,
	containers@...ts.linux-foundation.org,
	Netfilter Development Mailinglist 
	<netfilter-devel@...r.kernel.org>,
	Ben Greear <greearb@...delatech.com>,
	Serge Hallyn <serue@...ibm.com>,
	Matt Helsley <matthltc@...ibm.com>
Subject: Re: [RFC][PATCH] ns: Syscalls for better namespace sharing control.

Eric W. Biederman wrote:
> Pavel Emelyanov <xemul@...allels.com> writes:
> 
>> Eric W. Biederman wrote:
>>> Pavel Emelyanov <xemul@...allels.com> writes:
>>>
>>>> Thanks. What's the problem with setns?
>>> joining a preexisting namespace is roughly the same problem as
>>> unsharing a namespace.  We simply haven't figure out how to do it
>>> safely for the pid and the uid namespaces.
>> The pid may change after this for sure. What problems do you know
>> about it? What if we try to allocate the same PID in a new space
>> or return -EBUSY? This will be a good starting point. If we manage
>> to fix it later this will not break the API at all.
> 
> Parentage.  The pid is the identity of a process and all kinds of things
> make assumptions in all kinds of strange places.  I don't see how
> waitpid can work if you change the pid.

Agree. But what if we enter a pid space, which is a subnamespace of a current
one? In that case parent will still see the task by its old pid. We can restrict
first version of entering with this rule as well and this restriction will not
block us in typical usecase (I mean enter a container from a host).

> glibc doesn't cope if you change someones pid.

OK, but what if we try to allocate the same pid returning -EBUSY on failure?

My aim is to provide even a restricted enter. For most of the cases this
should work and make our lives easier. So two restrictions currently:
a) enter a sub namespace
b) allocate the same pid as we have now

Hm? :)

>>> Definitely.  I only consider the current interface to be a mushy not
>>> set in stone.
>> OK. The interface is good. I just don't want you to send it for an inclusion
>> until we decide what to do with waiting.
> 
> Sure.  I am get a jump on 2.6.35 not aiming for inclusion this merge
> window.  There is plenty of time.

Good!

>> Poll is OK with me. As far as the notification is concerned - that's also
>> done in OpenVZ. If you are OK to wait for a week or two I can do it for net
>> namespaces.
> 
> Seems reasonable.

OK. I'll spend some time playing with it next week then.

> Eric
> 

Thanks,
Pavel
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html