Skip site navigation (1) Skip section navigation (2)

Re: Spoofing as the postmaster

From: Mark Mielke <mark(at)mark(dot)mielke(dot)cc>
To: Gregory Stark <stark(at)enterprisedb(dot)com>
Cc: Trevor Talbot <quension(at)gmail(dot)com>, Tomasz Ostrowski <tometzky(at)batory(dot)org(dot)pl>, Magnus Hagander <magnus(at)hagander(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org, Bruce Momjian <bruce(at)momjian(dot)us>, Brendan Jurd <direvus(at)gmail(dot)com>
Subject: Re: Spoofing as the postmaster
Date: 2007-12-24 16:21:46
Message-ID: 476FDC9A.7090703@mark.mielke.cc (view raw or flat)
Thread:
Lists: pgsql-hackers
Gregory Stark wrote:
> "Mark Mielke" <mark(at)mark(dot)mielke(dot)cc> writes:
>   
>> UNIX socket kernel credential passing was mentioned in an earlier post, but I
>> didn't see it raised again. 
>>     
>
> I mentioned getsockopt(SO_PEERCRED) which isn't the same as credential
> passing. It just tells you what uid is on the other end of your unix domain
> socket.
>
> I think it's much more widespread and portable than credential passing which
> was a BSD feature which allowed you to send along your kernel credentials to
> another process. So you could, for example, open a file in psql then pass the
> file descriptor to the backend to have the backend read directly from the
> file
I agree - I forgot there were different flavours. I think any of these 
are just as good as SSL with public key authentication, and perhaps a 
lot cheaper in terms of performance. The only piece of information 
missing is the uid to compare against, which may as well be provided in 
the db open parameters the same as any other parameters might be provided.

Cheers,
mark

-- 
Mark Mielke <mark(at)mielke(dot)cc>

In response to

Responses

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2007-12-24 16:50:30
Subject: Re: Spoofing as the postmaster
Previous:From: Gregory StarkDate: 2007-12-24 04:33:39
Subject: Re: Spoofing as the postmaster

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group