Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!netsys!macomh!macom1!larry
From: larry@macom1.UUCP (Larry Taborek)
Newsgroups: comp.unix.questions
Subject: Re: Servers, sockets & security
Message-ID: <4871@macom1.UUCP>
Date: 27 Jul 89 21:13:29 GMT
References: <2293@auspex.auspex.com>
Distribution: na
Organization: CENTEL Federal Systems, Reston, VA. 22091-1506
Lines: 34

From article <2293@auspex.auspex.com>, by guy@auspex.auspex.com (Guy Harris):
>>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....

[some stuff deleted]

Gee, I don't know much about sockets, but why couldn't you, when
you fork the child, have the first packet exchanged hold some
sort of validation information.  Say the password of root of both
machines is traded between both machines, and verified in a
table local to each.  If they verify that they have a good
connection, then normal communications starts up.  Otherwise, log
files are written to, bells sound and the communications session
is terminated.

Of course, the verification information could be ANYTHING, and
not necessarily passwords.

Hope this helps...

Larry
-- 
Larry Taborek	..!uunet!grebyn!macom1!larry	Centel Federal Systems
		larry@macom1.UUCP		11400 Commerce Park Drive
						Reston, VA 22091-1506
						703-758-7000