linux-kernel - Re: [PATCH RFC] pidns: introduce syscall getvpid

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] [day] [month] [year] [list]

Date:	Tue, 22 Sep 2015 16:00:23 -0500
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Konstantin Khlebnikov <khlebnikov@...dex-team.ru>
Cc:	"Serge E. Hallyn" <serge@...lyn.com>,
	Chen Fan <chen.fan.fnst@...fujitsu.com>,
	linux-api@...r.kernel.org, containers@...ts.linux-foundation.org,
	Serge Hallyn <serge.hallyn@...ntu.com>,
	Oleg Nesterov <oleg@...hat.com>, linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH RFC] pidns: introduce syscall getvpid

Konstantin Khlebnikov <khlebnikov@...dex-team.ru> writes:

> On 21.09.2015 17:22, Serge E. Hallyn wrote:
>>
>> So please implement it, as Eric suggested, using the ns inode fds
>> instead of racy pid_t hints for namespaces.
>>
>
> I don't want to loose simple way to use it.
> Sometimes caller cannot prevent races (task its child or
> locked with with ptrace) or it don't care about them.
>
> What about this design:
>
> pid_t getvpid(pid_t pid, pid_t source, pid_t target)
>
> pid > 0 - get vpid of task
> pid = 0 - current pid (= just for symmetry =)
> pid < 0 - get vpid of parent task (ppid of -pid)
>           [ that's really useful for poking isolated pidns ]
> source/target > 0 - pid of source/target task
> source/target = 0 - use current as source/target
> source/target < 0 - use pidns fd (1-arg) as source/target
>
> or the same but without =0 sugar:
>
> pid > 0 - get vpid of task
> pid < 0 - get vpid of parent task (ppid of -arg)
> source/target > 0  - pid of source/target task
> source/target <= 0 - use pidns fd (-arg) as source/target
>
> libc caches current pid, extra getpid shouldn't be a problem.

Yuck.  An invalid fd like for saying use the current pid namespace is
fine.

Using pids to identify namespaces yuck just yuck.  That just seems to
add complexity for no gain except to make programs buggier.

We have a couple of old interfaces that use pids because pids were the
the best we had, but at this point I don't see anything at all that
even suggests that pids are a good choice for identifying namespaces.

If performance is important than caching file descriptors should be
trivial.  If performance is not important it should not be hard to
open "/proc/<pid>/ns/pid".

I do not see the gain of using pids in this interface except to confuse
people, and make the interface brittle.


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/