Attaching file descriptors to processes with CLONE_FD

Posted Apr 2, 2015 17:31 UTC (Thu) by josh (subscriber, #17465)
In reply to: Attaching file descriptors to processes with CLONE_FD by iq-0
Parent article: Attaching file descriptors to processes with CLONE_FD

> Radical idea: Make the filedescriptor actually be a the proc directory?

We did consider that during the design. We also considered making the "get file descriptor for existing process" mechanism be open("/proc/$PID/clonefd") or similar. However, that approach would require that /proc is mounted, and would raise interesting interaction issues with containers. The kernel has been moving in the opposite direction; for instance, see execveat, which was created specifically as an alternative to execve of /proc/self/fd/N because the latter requires a mounted /proc.

Attaching file descriptors to processes with CLONE_FD

Posted Apr 3, 2015 7:04 UTC (Fri) by iq-0 (subscriber, #36655) [Link]

I'm not saying it should be mounted, but I must admit that I don't know enough about the internals of procfs to know if you could open an fd internally.

I guess it would be a security risk, because a process could this way get a procfs handle, follow that to '..' and have access to it's entire procfs even if the admin chose not to mount it (chroot escaping for root processes would probably become easier this way, though that is officially not considered a security mechanism).

But I don't see how the 'open(/proc/$pid/clonefd)' would introduce a dependency on procfs. Only the feature "open a process fd for an existing process" would require that. The fd itself wouldn't necessarily have to be tied to procfs in this case (as it would in the fd for task directory).