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

Re: Help with access control settings in pg_hba.conf --

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruno Wolff III <bruno(at)wolff(dot)to>
Cc: Victor Danilchenko <danilche(at)cs(dot)umass(dot)edu>,pgsql-admin(at)postgresql(dot)org
Subject: Re: Help with access control settings in pg_hba.conf --
Date: 2005-01-28 22:53:10
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-admin
Bruno Wolff III <bruno(at)wolff(dot)to> writes:
>   Victor Danilchenko <danilche(at)cs(dot)umass(dot)edu> wrote:
>> the solution was in disabling the 'result:encrypt' option
>> (setting it to 'no') in the /etc/identd.conf file.

> When you encrypt names for ident, the other host isn't supposed to be
> able to figure out who is making the request. If the remote site has
> a problem they can give the string back to the connecting site's admins
> and then they can figure out who is causing problems.

I have added a note to our SGML docs pointing out that this doesn't work.

In one sense it *should* not work, by design, since the whole point of
an encrypting ident server is to not let the remote side figure out the
real name of its user.  However, we already point out that

    [ident is] only appropriate for closed networks where each client
    machine is under tight control and where the database and system
    administrators operate in close contact. 

You could argue that in this scenario it is appropriate for the database
to have a copy of the encryption key that the client's ident server is
using, and then it would be just a small matter of programming to make
PostgreSQL accept encrypted responses.  I'm not sure it's worth the
trouble though.  One problem is that so far as I've been able to find,
there is not a recognized standard for the encryption transformation,
and so you might need different code for each ident server
implementation you deal with.  Also, at least some ident servers can
be configured to deliver encrypted responses to some questioners and
unencrypted responses to others --- so the simplest solution is to use
one of those and configure it to give cleartext responses to your
database server.

			regards, tom lane

In response to

pgsql-admin by date

Next:From: Michael FuhrDate: 2005-01-28 23:45:07
Subject: Re: SET command
Previous:From: Roderick A. AndersonDate: 2005-01-28 22:48:19
Subject: SET command

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