Socket listening

Socket listening

Post by Amos Shapi » Sun, 19 Nov 1995 04:00:00



   Hello,

   I am modifying code to listen in on a socket and wanted to know how I could
   read the kernel table that associates sockets with shell users?? Is this
   possible ( it has to be! ). I assume there is a table in memory that
   associates a pid or something with an open socket??

I'm not familiar with Linux internals, but I think you are missing
something.

The point is that a socket might be referenced by two different
processes owned by two different users (e.g. a daemon accepting a
connection, forks and the child changes uid, both processes now have
the socket in the fd table), therefore there is no one-to-one mapping
between sockets and uid's, not to mention pid's.

If Linux manages files like UNIX then the situation described above will
result in something generally like:

parent-process-fd-table:  ...              FILE table
                          fd x-------`
                                     |
                                     +-----entry z, contains
child-process-fd-table:   ...        |     or references socket's
                          fd x-------'     info

(they would probably have the socket pointed from the same fd ("fd x")
because that's the result of a fork, but they might very well point
from different fd numbers inside their private fd tables.  This is
said just to clarify the distinction between a process FD table and
the system-wide FILE table)

What I'd recommand (but you might find a better answer) is that you
scan the fd tables of all processes and find which one of them
reference the socket you are looking for, take into consideration the
possibility of multiple results.  (of course, you have to wade through
the FILE table and maybe other tables in order to determine which
entry in the FILE table corresponds to your socket)

Hope this helps,

Cheers,

--Amos

(PS I've been twice to God-Zone, where are you posting from?)
--
--Amos Shapira                      | "Of course Australia was marked for
133 Shlomo Ben-Yosef st.            |  glory, for its people had been chosen
Jerusalem 93 805                    |  by the finest judges in England."

 
 
 

Socket listening

Post by roo » Mon, 20 Nov 1995 04:00:00



>  I'm not familiar with Linux internals, but I think you are missing
>  something. ...
>  The point is that a socket might be referenced by two different
>  processes owned by two different users (e.g. a daemon accepting a
>  connection, forks and the child changes uid, both processes now have
>  the socket in the fd table), therefore there is no one-to-one mapping
>  between sockets and uid's, not to mention pid's. ...

  A nit:  when the socket is created, it has the uid/gid of the process
that created it stored in it's internals (see sock_alloc() in net/socket.c
of your linux kernel).  When you accept() on a socket, you get a new
socket also created with sock_alloc(), which should end up with whatever
the current uid/gid happen to be at that moment.

  Someone always owns it.  It may not be who you'd like it to be, but
someone unique always owns it.

  Your UID argument may be flawed, but your PID argument is not.

 
 
 

1. How do I keep a socket listening while already handling connected clients??

Hi! I need some help/clarifications with the following:

I have my server setup a socket and wait for clients to connect on the
designated port. However, I want to be able to deal with mutiple clients.
The way I'm doing it right now is that I'm forking a child everytime a
connection is made. This APPEARS simple however introduces the problem of
dealing with mutual exclusions, etc. Is there a better way to implement
this?

Thanx
Twistted

2. Proxy authentication on FreeBSD 4.3

3. Solaris 7 limit on socket listen queue

4. nmap as non root

5. "ping" remote host to see if socket listening

6. kernel compilation problem MPU401 - Redhat 5.0

7. multiple IP's at startup

8. Socket listen fails with no error code

9. TCP socket listen queue

10. "ping" remote host to see if socket listening

11. Socket listening

12. hpux 11 - sockets - listen queue problem