Re: server authentication over Unix-domain sockets

(2010/06/11 21:11), Stephen Frost wrote:
> * Magnus Hagander (magnus(at)hagander(dot)net) wrote:
>> On Fri, Jun 11, 2010 at 14:07, Stephen Frost<sfrost(at)snowman(dot)net> wrote:
>>> I definitely like the idea but I dislike requiring the user to do
>>> something to implement it. Thinking about how packagers might want to
>>> use it, could we make it possible to build it defaulted to a specific
>>> value (eg: 'postgres' on Debian) and allow users a way to override
>>> and/or unset it?
>>
>> Well, even if we don't put that in, the packager could export a global
>> PGREQUIREPEER environment variable.
>
> Yeahhhh, no, that's a crappy solution, sorry. :) I've been down that
> road with people trying to monkey with /etc/bashrc; oh wait, not
> everyone uses bash, and having every package screw with that stuff is
> equally horrible. Admittedly, in this specific case, Debian could
> implement what you're talking about in it's wrapper system, maybe, but I
> still don't like it and if people don't use the wrapper (I can imagine
> cases why that might happen, tho I havn't ever had to myself), they
> wouldn't get the benefit..
>
Are you suggesting the packager enforces a certain unix user on the
installation time, although 'postgres' shall be used in most cases?

Let's back to the purpose of the feature.
In my understanding, it provides the client process the way to verity
user identifier of the server process before sending password.
Indeed, if we provide a default value of the "requirepeer" using
environment variable, the client process can override its own setting.
But is there any problem?

This option allows the client process to specify an expected user
identifier of the server process, then libpq closes the connection
if not matched.
Even if the default shall be given from the system default, the
client can provide an explicit alternative in the connection string.
Is there any fundamental differences to the environment variable?

Thanks,
--
KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>