linux-kernel - Re: [PATCH 7/7][v8] SI_USER: Masquerade si

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:	Thu, 19 Feb 2009 15:51:59 -0800 (PST)
From:	Roland McGrath <roland@...hat.com>
To:	ebiederm@...ssion.com (Eric W. Biederman)
Cc:	Oleg Nesterov <oleg@...hat.com>,
	Sukadev Bhattiprolu <sukadev@...ux.vnet.ibm.com>,
	Andrew Morton <akpm@...l.org>, daniel@...ac.com,
	Containers <containers@...ts.osdl.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 7/7][v8] SI_USER: Masquerade si_pid when crossing pid ns boundary

> Suppose I have 3 processes in a process group in three separate pid
> namespaces.
> 
> Looking from the init pid namespace I have:
>      pid pgrp ppid
>       10 10    1
>       11 10    10
>       12 10    11
> 
> Looking from the pid namespace of pid 11 I have:
>      pid pgrp ppid
>       0  0     0
>       1  0     0
>       2  0     1
> 
> Looking from the pid namespace of pid 12 I have:
>      pid pgrp ppid
>       0  0     0
>       0  0     0
>       1  0     0
> 
> So if the process with pid 12 in the initial pid namespace
> sends to process group 0.

There is no "process group 0".  0 means "the sender's pgrp".

One possibility is that perhaps what people really want the pid_ns to mean
is that "the sender's pgrp" in the view of the sender does not include any
processes outside its pid_ns scope.  That would be consistent with the
behavior of kill (kill_something_info) on -1; it's described as "all
processes", but in fact means "all processes within my pid_ns scope".

What I mean to describe there is changing kill_something_info, so that
e.g. killpg() inside the NS would affect only the NS init itself but e.g.
^Z (effectively an implicit killpg() that's always from the global NS)
would also go to that init's "mother" pgrp in the outer NS.

Another possibility is to decide that's just not worth having at all, and
CLONE_NEWNS should just implicitly reset pgrp to self.  That is simple.
But perhaps today someone has a script running a pid_ns-world whose init is
gracefully killed by ^C of the whole script and we wouldn't want to break
that if it is actually useful now.

> pid 10 should see si_pid 12.
> pid 11 should see si_pid 2.

We indeed have this problem if we think it's useful to continue to have
a concept of pgrp for the sub-init that can see outside its own NS.

> Neither should see si_pid 0, as from_ancestor_ns will not be true.

Perhaps replace from_ancestor_ns with struct pid_namespace *sender_ns?
(I don't know if there was already a can of worms with such an idea before.)
Then si_pid could be translated as appropriate for each recipient.
(Or perhaps just struct pid *sender and reset si_pid from that.)

Thanks,
Roland
--
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/