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]
Message-ID: <m1fxzmbhsy.fsf@ebiederm.dsl.xmission.com>
Date:	Sun, 04 Nov 2007 01:17:49 -0600
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	sukadev@...ibm.com
Cc:	Pavel Emelyanov <xemul@...nvz.org>,
	Ulrich Drepper <drepper@...hat.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Ingo Molnar <mingo@...e.hu>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, Serge Hallyn <serue@...ibm.com>,
	Oleg Nesterov <oleg@...sign.ru>
Subject: Re: [patch] PID namespace design bug, workaround

sukadev@...ibm.com writes:

> Pavel Emelianov [xemul@...nvz.org] wrote:
> | Ulrich Drepper wrote:
> | > -----BEGIN PGP SIGNED MESSAGE-----
> | > Hash: SHA1
> | > 
> | > Pavel Emelyanov wrote:
> | >>> Isn't it this?
> | >>>
> | >>> http://lkml.org/lkml/2007/11/1/141
> | >> That was the initial problem, and I already answered to Ingo about
> | >> it
> | > 
> | > No, look at my old mail which Ingo referenced in that posting.
> | 
> | You pointed only one problem that is not a variation of "how do 
> | we handle the case when we pass our pid outside the namespace".
> | 
> | This problem with signals is now being resolved at IBM by Sukadev 
> | and Serge (I put them in Cc), so this is about to be fixed by the
> | time 2.6.24 releases (I hope).
>
> Yes. We (Oleg, Eric included in Cc) have a patchset to address signals
> issues in child pid namespaces. It is being discussed on Containers list:
>
> https://lists.linux-foundation.org/pipermail/containers/2007-October/008240.html
>
> We will post the patchset to LKML soon.

Yes.  Getting all of the cross namespace cases working that we can is a
goal.  Currently I don't know if we can do better with the futexes that
have pids in the user/kernel ABI.  Plain futexes should be fine.

Implementation wise si_pid is a bit of a pain but we should have that
one sorted out shortly.  It is a well understood and we just need to get
the code right.

The pids in the sysvipc space should also be fairly simple to handle
just do a classic struct pid conversion.  And convert from struct pid
to a pid_t right at the user/kernel interface.

Unless I missed something we already properly handle giving people
usable pids from the tty layer.

Getting pids working properly for unix domain socket credential when
we cross pid namespaces is another case that needs a struct pid
conversion to get things working, but the kernel should be able to
do the right thing at that point.

In summary when pids are stored inside the kernel we have all of the
needed infrastructure with struct pid to handle doing the right
thing processes communicate between pid namespaces.

Right now we just need to go through every place in the kernel make
certain we haven't over looked something we can handle.  And there
are a lot of places where the kernel uses pids....

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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ