Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!gem.mps.ohio-state.edu!ginosko!uunet!auspex!guy
From: guy@auspex.auspex.com (Guy Harris)
Newsgroups: comp.unix.questions
Subject: Re: Servers, sockets & security
Message-ID: <2293@auspex.auspex.com>
Date: 26 Jul 89 20:44:35 GMT
References: <2914@mit-caf.MIT.EDU>
Reply-To: guy@auspex.auspex.com (Guy Harris)
Distribution: na
Organization: Auspex Systems, Santa Clara
Lines: 27

>What I'd like to know is: how can I verify the identity of a client
>seeking to sign off?  This is to say, how can I keep someone from
>creating a bogus client which falsifies it's owner's ID in order to
>sign other users off?  I don't know of any way to determine the pid of
>the process at the other end of a socket -- is there any?

No.  Given that, in general, the "process at the other end of the
socket" may not even *have* a PID - for example, MS-DOS doesn't have
processes, much less PIDs - it's not surprising that there's no way to
determine the pid....

Furthermore, even in the case of UNIX-domain sockets, there isn't
necessarily a single "process at the other end of the socket" - a socket
is represented by a file descriptor, and a process can pass them on to
children (or even to unrelated processes over UNIX-domain sockets).

>Or should I deny write access to the socket to all but its owner, and
>run the client programs setuid?

That's one way of doing it.  Of course, if you do that, and the sockets
are UNIX-domain sockets (as the comment about denying write access
implies), you could have the client run with a user or group ID with
write access to the schedule file, and not bother with the server....

Another way might be to use some mechanism such as Kerberos, and require
the client to provide some sort of validated cookie to prove who they
are.