linux-kernel - Re: [PATCH RFC] procfs: add pidnr file

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:	Wed, 26 Jun 2013 15:26:47 -0500
From:	Serge Hallyn <serge.hallyn@...ntu.com>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
Cc:	linux-kernel@...r.kernel.org,
	"Daniel P. Berrange" <berrange@...hat.com>,
	containers@...ts.linux-foundation.org,
	Colin Ian King <colin.king@...onical.com>,
	Stéphane Graber <stgraber@...ntu.com>
Subject: Re: [PATCH RFC] procfs: add pidnr file

Quoting Eric W. Biederman (ebiederm@...ssion.com):
> Serge Hallyn <serge.hallyn@...ntu.com> writes:
> 
> > Add a file called pidnr under /proc/task/.  Reading this file gives the
> > pid of /proc/task in the reading task's namespace (or 0 if there is no
> > valid pid).
> >
> > This fills a need currently not solvable at all.  The particular need I
> > have for it is so that a task inside a container can pass requests to a
> > task outside the container (using an open fd for /proc/task) to have the
> > target task moved to a new cgroup.  Others have asked for this ability
> > for other reasons.
> 
> This is solvable today.  Just pass the pid using SCM_CREDENTIALS over a
> unix domain socket between the two processes.  That is actually better
> because a task can't claim to be a member of another task.  You already
> have the unix domain socket if you are using SCM_RIGHTS to pass file
> descriptors.

Hm, yeah, that should work.  (I was thinking I had to do a
getpeercon-like thing where I could only get the ucreds of the
task which opened the socket).  I'll try it to see if there are 
any gotchas.

Note though that this doesn't help the general admin case, because
it requires a program (and not a one-liner) running in the container.
So I can't just do

	cat /proc/`pidof container-init`/root/proc/200/pidnr"

to figure out the corresponding pid in my own ns.  Whereas that cat
doesn't require me to execute anything inside that container.

Wonder if coreutils should ship a program which clones a task in
same netns but target pidns, and sends ucred.pid = atoi(argv[1])
from that pidns to the first task which prints out what it reads.

That should be a tidy, purely userspace solution to the general admin
problem.  Only downside being that it requires the rights to setns to
the pidns, instead of just read access to its /proc.

thanks,
-serge
--
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/