Re: How to check UID of process on the other side of local TCP/UDP connection

does doing a netstat and matching the client port with a pid work for you?

netstat -taonp
tcp        0      0 10.100.40.2:2617        69.31.131.44:22         ESTABLISHED 6038/ssh            keepalive (5790.02/0/0)

so the client/port 10.100.40.2:2617 is pid 6038

the server knows the following about the client:
source port
IP

so if I match sourceip:sourceport from the active connections table and 
look for the pid matching that entry...

does that work for you? perhaps I misunderstood your question

-Eric

On Fri, 24 Nov 2006, [email protected] wrote:

> Hello.
>
> I have the following situation:
> - Client communicates with server via TCP or UDP.
> - Both client and server are on the same local host.
> - Server runs with root privilege.
>
> Now, client connects to server. Server has to check uid of the client. How it can be done?
> I need a solution that can be ported to all modern Unix and Linux systems.
>
> The most simple solution I came with is as follows:
> 1. Client connects to server.
> 2. Server asks client to create file with random name, for example /tmp/check.6723
> 3. Client generates the file.
> 4. Server checks the owner of the file.
>
> The owner of the file is the UID under which client is running.
>
> But
> the problem is that it requires some additional communication between
> server and client. My programs can communicate hundreds times a second
> so creating, checking and removing the file is a big performance issue.
>
> Do you have any ideas how this local authentication can be achieved in some different way?
>
> I
> was also thinking about using Unix sockets for communication, but it
> seems that they also lack any mechanism for authenticating the client.
> Anyways, I would prefer to stick with TCP/UDP, because this is what my
> programs use already, and  I don't really want to change everything to
> Unix sockets (unless of course Unix sockets are the only good way to
> resolve my problems).
>
> Thanks,
> Ola
>
>
>
>
>