On Linux, you can interfere with any process via the process filesystem typically mounted at /proc in several creative ways, given you have access rights to a particular process. CAP_SYS_PTRACE isn't just for the ptrace syscall, but also for access inside /proc. The open file descriptors of Linux processes are exposed via /proc/$PID/fd/$FD as pseudo symlinks, further meta data about the fds then via /proc/$PID/fdinfo/$FD. This information is quite useful, for instance, for detecting "leaked fds" in Go unit tests, using the fdooze <https://github.com/thediveo/fdooze> package. The way /proc works in Linux, you can even detect fd leakage of a separate process under test.
As the /proc/$PID/fd/$FD elements in the procfs are (pseudo) symlinks, you can readlink them to see what they're connecting to (with some caveats), as well as you can use them as path references in opening them. For instance, CLI programs that cannot read from stdin, but always want a file name and don't understand "-", the usual way around is to specify /proc/self/fd/0. However, in this case you simply open a new fd using a resource's name referenced by an fd of the process. But the Linux kernel since quite some time has pidfd_getfd(2) <https://man7.org/linux/man-pages/man2/pidfd_getfd.2.html> to clone an fd of a "victim" process into a new fd of your own "interested" process. For instance, this allows my lxkns discovery engine to pick up Linux kernel namespace references from the sockets and other open fds which processes currently have open, even if there is no other reference left in the system to a particular namespace. Some elements are difficult to mess with: while you might know their inode number you simply cant access/open them knowing only the inode. For instance, you cannot access Linux kernel namespace by their inode numbers. Instead, you either need an already referencing fd or the special /proc/$PID/ns/* paths, that, then opened, reference the particular namespace. Finally, Linux additionally uses "anonymous inodes" that don't have an associated inode, such as IIRC eventfd, epoll, and others. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/37c752f6-e1e3-4213-bab7-06f14e1cc3d5n%40googlegroups.com.
