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

Pre-scriptum:

I solved the problem, but the text message I originally composed is left
intact in case someone else needs it to help debug IDENT problems.

    the solution was in disabling the 'result:encrypt' option
(setting it to 'no') in the /etc/identd.conf file. Once I did that,
IDENT started returning plaintext names instead of encrypted strings,
and clearly PostgreSQL ident client doesn't know how to handle encrypted
IDENT responses. Something to fix in the future release perhaps? or
maybe it's fixed already...

------------------------------------------------------------------------

    Old mesage:

    I have been doing some more investigation, and it looks like the
problem is with the malfunctioning identd server. it never returns the
username -- always replies 'USERID : OTHER', even though on clientside,
I can see it deriving the correct userid. I have tested this on multiple
systems and Linux releases, so I think this is something i am doing
wrong...

    On client side:

# identd -b -d
[Pidentd, version 3.0.16 (compiled for Linux 2.4.21-4.ELsmp) - Apr 14 2004 12:14:17]
kernel_thread() started
kernel_thread() started
timeout_thread() started
entering server main loop

request_thread: fd#7: start
timeout_create(120, ...) -> 09f9cb70
handle_request: fd#7: '1926,7666'
remote = xxx.xxx.xxx.xxx:7666
local = xxx.xxx.xxx.xxx:1926
ka_lookup(), attempt = 1, status = 1
kernel_query, status = 1
        euid = 1028
send_result(7) - ruid = -1, euid = 1028
timeout_reset(09f9cb70, 120)

    On server side:

[root@elsrv4 init.d]# telnet clienthost 113
Escape character is '^]'.
1926,7666
1926, 7666 : USERID : OTHER :[0RPlNgpZPzlJNeS5JzOol2J1fsNGUMd8]


    As I understand it, it's supposed to return the actual userid
instead of 'OTHER'. Any ideas about what's going wrong?..


On Thu, 27 Jan 2005, Victor Danilchenko wrote:

>On Thu, 27 Jan 2005, Victor Danilchenko wrote:
>
>>    Hi,
>>
>>    I am trying to set up a database server with multiple DB
>>clusters, so that in each cluster a number of users have their own
>>database each, with passwordless access (we can trust the network
>>security in our installation). The following is what seems like it
>>*should* work:
>>
>>host    all             all     127.0.0.1       255.255.255.255 password
>>host    sameuser        all     xxx.xxx.xxx.0   255.255.255.128 ident sameuser
>>host    all             @fac    xxx.xxx.xxx.0   255.255.255.128 trust
>>
>>    The second line ("host sameuser") is the problem. It doesn't
>>work -- when tryign to connect, I keep getting error messages:
>>
>>$ whoami
>>testuser
>>$ psql -h db-edlab -p 7666 testuser testuser
>>psql: FATAL:  IDENT authentication failed for user "testuser"
>
>    I forgot to mention that yes, I do have identd daemon running on
>the connecting system -- from the RHL pidentd RPM.
>
>>    If I replace 'ident sameuser' with 'trust' there, it works fine
>>-- but then any user can access anyone else's database, providing they
>>request the same password.
>>
>>    The idea is that each user should be able to access only their
>>database, only as themselves, without password -- but I can't figure out
>>what I am doing wrong. Any help? if what I am trying to do is
>>impossible, is there any other way to achieve such a goal -- i.e.
>>passwordless access that allows each user to access only their own
>>database over the network?
>>
>>
>>    BTW, as long as I am writing, a somewhat related question, which
>>is not nearly as important as the previous one.
>>
>>    I launch multiple postmatser processes, each servicing a
>>dedicated DB cluster on a dedicated port. The problem is that I only
>>ever see *one* local UNIX socket (/tmp/.s.PGSQL.<portnumber>) file.
>>There is a .lock file created corresponding to each server/port combo,
>>but it looks like each subsequent instance of the postmaster kills the
>>previous instance's UNIX socket. Is this how it should be -- and if so,
>>are there any pg_ctl options I can pass in to make it simply not create
>>the UNIX sockets altogether, so that only network operations are
>>supported? AT the moment, I am doing admin access though the loopback
>>device, so it's not a big issue.
>>
>>
>
>

--
|  Victor  Danilchenko  | If you can keep your head when all about |
| danilche@cs.umass.edu | you people are losing theirs, then you   |
|   CSCF   |   5-4231   | clearly don't understand the situation   |