What do /proc/fd file descriptors show?

Question

Learning about the /proc/ directory today, in particular I'm interested in the security implications of having all the information about a process semi-publicly available, so I wrote a simple program that does some simple whatnot that allows me to explore some properties of the /proc/ directory:

#include <iostream>
#include <unistd.h>
#include <fcntl.h>

using namespace std;

extern char** environ;

void is_linux() {
#ifdef __linux
   cout << "this is running on linux" << endl;    
#endif
}

int main(int argc, char* argv[]) {
  is_linux();

  cout << "hello world" << endl;
  int fd = open("afile.txt", O_RDONLY | O_CREAT, 0600);
  cout << "afile.txt open on: " << fd << endl;

  cout << "current pid: " << getpid() << endl;;

  cout << "launch arguments: " << endl;
  for (int index = 0; index != argc; ++index) {
    cout << argv[index] << endl;
  }

  cout << "program environment: " << endl;
  for (char** entry = environ; *entry; ++entry) {
    cout << *entry << endl;
  }

  pause();
}

Interestingly though (to me anyway), when I check the file-descriptors folder (/pid/<PID#>/fd), I see this:

root@excalibur-VirtualBox:/proc/1546/fd# ls -l
total 0
lrwx------ 1 root root 64 Nov  7 09:12 0 -> /dev/null
lrwx------ 1 root root 64 Nov  7 09:12 1 -> /dev/null
lrwx------ 1 root root 64 Nov  7 09:12 2 -> /dev/null
lrwx------ 1 root root 64 Nov  7 09:12 3 -> socket:[11050]

why do the file descriptors point to /dev/null? Is that to prevent user's from being able to inject content into a file without actually being the process itself, or am I off base on that? And even more curious, why does the file descriptor to an open file point to a socket? That seems really odd. If anyone can shed some light on this for me, I would really appreciate it. Thanks!

Solution

You are definitely looking at the wrong /proc directory (for other PID or on another computer). The contents of /proc/<pid>/fd for your program should look like here:

lrwx------ 1 user group 64 Nov  7 22:15 0 -> /dev/pts/4
lrwx------ 1 user group 64 Nov  7 22:15 1 -> /dev/pts/4
lrwx------ 1 user group 64 Nov  7 22:15 2 -> /dev/pts/4
lr-x------ 1 user group 64 Nov  7 22:15 3 -> /tmp/afile.txt

Here we can see that file descriptors 0, 1, and 2 are shown as symbolic links to the pseudo terminal in which the program is running. It could be /dev/null if you started your program with input, output, and error redirection. The file descriptor #3 points to the file afile.txt which is currently opened.

Comments

[twalberg]

Because the program was run something like my_program < /dev/null > /dev/null 2>&1... And because sockets are abstracted as file descriptors in Linux/Unix, and the program opened a socket to communicate with something... Also, I don't think the C code above is what's running in the process with PID 1546 at that moment...