0

I am using strace to track a program. In this line:

recvfrom(7, "\0\260R\0\0\1\364\6\215\r\257\330\210\341\0\270\240\0\260R\0\0\0\0\0\0\0\0\0\0\0\0"..., 3000, 0, {sa_family=AF_PACKET, proto=0x88e1, if4, pkttype=PACKET_OUTGOING, addr(6)={1, f4068d0dafd8}, [18]) = 60

the first seven is the file descriptor used to read (seen here).

Can I discover who opened that socket? I know that processes keep in /proc (I think?) their list of open files. So, could I find in the list of all processess who has that fd opened or something similar?

Thanks

Camandros
  • 443
  • You can find out what the fd points to with /proc/$pid/fd or lsof, but I don't this you can determine who "opened" that fd. - For a process to access a fd it has to open it on its own. – michas Jun 05 '15 at 11:44
  • 1
    File descriptors are local to the process, inherited from the parent, preserved across execve() unless they have the CLOSE_ON_EXEC flag. They point to an open file description which is created upon open()/socket()/accept()... A fd can be duplicated after which two fds can point to the same open file description. open file descriptions can be passed across between processes through ancillary messages on unix domain sockets. Most likely that socket will have been instiated by the process itself or one of its ancestors. – Stéphane Chazelas Jun 05 '15 at 11:52
  • 1
    Your question doesn't make much sense: your process opened the socket. Since you have the output of strace, look what operation returned fd 7 for more information (try grep '^open.* = 7$' first). Since it has sa_family=AF_PACKET, I'd say this is your process communicating with a device. – lcd047 Jun 05 '15 at 14:14
  • Try to get the program at the other side of the socket with netstat -ap (requires root to see the program name). – ott-- Jun 07 '15 at 01:06

1 Answers1

0

You can't discover who opened the socket, but a program can't open a file in another program, so the socket either was opened by the process you're tracing (or one of ancestors that later forked), or was already open when you invoked the program (which is unlikely if this is a socket used by the program).

So look further up in the trace until you find the system call that caused file descriptor 7 to be opened. For a socket, this is probably either connect if that process is a client or accept if it's a server. The call could also be one that shuffles file descriptors around, such as dup2, in which case you'll then want to trace the descriptor that was duplicated.

If you want to know what other process the socket is communicating with, see Who's got the other end of this unix socketpair?

Community
  • 1
Gilles 'SO- stop being evil'
  • 829,060