
Apologies if this has been asked before, but the mailing list archive seems
to be down again.

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?


----------------------------------------------------------------
Philip Warner                    |     __---_____
Albatross Consulting Pty. Ltd.   |----/       -  \
(A.C.N. 008 659 498)             |          /(@)   ______---_
Tel: (+61) 0500 83 82 81         |                 _________  \
Fax: (+61) 0500 83 82 82         |                 ___________ |
Http://www.rhyme.com.au          |                /           \|
                                 |    --________--
PGP key available upon request,  |  /
and from pgp5.ai.mit.edu:11371   |/

Sat, 29 Jul 2000 00:30:56 +1000
Philip Warner <pjw@rhyme.com.au>
Security choices...
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?

			regards, tom lane

Fri, 28 Jul 2000 12:25:18 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Security choices... 
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?


----------------------------------------------------------------
Philip Warner                    |     __---_____
Albatross Consulting Pty. Ltd.   |----/       -  \
(A.C.N. 008 659 498)             |          /(@)   ______---_
Tel: (+61) 0500 83 82 81         |                 _________  \
Fax: (+61) 0500 83 82 82         |                 ___________ |
Http://www.rhyme.com.au          |                /           \|
                                 |    --________--
PGP key available upon request,  |  /
and from pgp5.ai.mit.edu:11371   |/

Sat, 29 Jul 2000 02:39:21 +1000
Philip Warner <pjw@rhyme.com.au>
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

Fri, 28 Jul 2000 21:53:34 +0100
Malcolm Beattie <mbeattie@sable.ox.ac.uk>
Re: Security choices...