Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email email@example.com
Re: How to check UID of process on the other side of local TCP/UDP connection
Date: Mon Nov 27 2006 - 14:23:26 CST
does doing a netstat and matching the client port with a pid work for you?
tcp 0 0 10.100.40.2:2617 126.96.36.199: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:
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
On Fri, 24 Nov 2006, rainmailbox2001-olayahoo.ca wrote:
> 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.
> 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?
> 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).