Re: Security choices...

Philip Warner writes:
> At 12:25 28/07/00 -0400, Tom Lane wrote:
> >Philip Warner <pjw@rhyme.com.au> writes:
> >> Is there any reason that a security model does not exist for psql that
> >> allows Unix user 'fred' to log in as PG user 'fred' with no password etc,
> >> but any user trying to log on as someone other than themselves has to
> >> provide a password?
> >
> >Define "log in as themselves" --- in particular, how will you check?
> 
> I was thinking (in a very blinkered way) of client processes on the same
> machine as the postmaster. Admitedly, I had not considered network access etc.
> 
> Even in this limited form, it does not seem too bad; is there a way the
> postmaster can tell (a) the client is on the same machine, and (b) what the
> process username is?

You can tell whether someone is connecting via a Unix domain
socket (client on same machine) or an Internet domain socket
(remote machine or someone using localhost loopback or similar
for some reason). If it's a Unix domain socket then modern Unices
usually provide a way to find out who (i.e. the uid/gid which can
then be mapped to a username/groupname). The problem is that there's
no standard API to do so. Some ways need the cooperation of the
client to send a special "tell the peer who I am" thingy (SCM_CRED
message); some ways don't (Linux getsockopt SO_PEER_CRED and the
STREAMS way). I submitted an example patch (using the simple Linux
API) a month or few back to implement "only let username connect to
own database" but it wasn't accept or worked on because of lack of
portability. On the plus side, I found a Linux kernel bug in that
area (socketpair sockets didn't initialise SO_PEER_CRED) so I got
one bug fix patch accepted out of it :-)

--Malcolm

-- 
Malcolm Beattie <mbeattie@sable.ox.ac.uk>
Unix Systems Programmer
Oxford University Computing Services