Re: [PATCH RFC] procfs: add pidnr file

[Serge Hallyn]

Quoting Eric W. Biederman (ebiederm@xxxxxxxxxxxx):
> Serge Hallyn <serge.hallyn@xxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/