Bruno Wolff III <bruno@wolff.to> writes:
> Victor Danilchenko <danilche@cs.umass.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