Обсуждение: bug with identd autentication

Sébastien BLON (sb@nfrance.com) reports a bug with a severity of 2
The lower the number the more severe it is.

Short Description
bug with identd autentication

Long Description
Hi

The postmaster backend seems to be blocked when the identd server of the peer
accepts the connection but does not respond. (ie if the load is too high
on the identd server for example)

In fact, identd is dying without closing the socket. I know that it
is an identd problem ( pident 3.012 )

The identification seems to be performed by the parent process,
not by a child. Postgres stops forking and does not accept
connections anymore. (See strace below)

The timeout seems to be not configurable.

If posgtres is not restarted or if we do not wait for 5 minutes or
more, Postgres keeps blocking.

I hope i am clear enough.

Sample Code
SYS_175(0x2, 0x81971e0, 0, 0x8, 0x2)    = 0
select(6, [3 4 5], [], NULL, NULL)      = 1 (in [5])
SYS_175(0x2, 0x8197260, 0, 0x8, 0x2)    = 0
read(5, "\0\2\0\0sintes\0\0\0\0\0\0\0\0\0"..., 292) = 292
open("/home/postgres/pg_hba", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/home/postgres/pg_hba.conf", O_RDONLY) = 6
fstat(6, {st_mode=S_ISVTX|0263, st_size=0, ...}) = 0
mmap(0, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x400150
00
read(6, "#\n# Example PostgreSQL host acc"..., 4096) = 4096
read(6, "USERAUTH are not allowed.\n\n# F"..., 4096) = 2597
close(6)                                = 0
munmap(0x40015000, 4096)                = 0
socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 6
bind(6, {sin_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("216.167.107.
199")}, 16) = 0
connect(6, {sin_family=AF_INET, sin_port=htons(113), sin_addr=inet_addr("216.167
.107.198")}, 16) = 0
send(6, "1920,5432\n", 10, 0)           = 10
recv(6,

No file was uploaded with this report

pgsql-bugs@postgresql.org writes:
> The postmaster backend seems to be blocked when the identd server of the peer
> accepts the connection but does not respond.

Yes, this is a known shortcoming --- it is (or should be) in the TODO list.

However, it hasn't been very high priority, because you shouldn't be
using ident auth anyway unless you trust the ident server on the other
end.  That trust extends to response time as well as reliability of
results...

            regards, tom lane

BLON Sébastien <sebastien.blon@nfrance.com> writes:
> We'd like to reduce the timeout in the case of identd faillures.
> Is it possible ?

I doubt it; if the ident server dies then it's really a TCP protocol
question as to how soon the postmaster will be told that.  (I do think
your remote site's kernel is at fault for not reporting the connection
closed immediately, though.)

> Is there any reason for the fact that it is the parent process
> which deals with the authentication instead of a child ?

Well, the way that this should be fixed within the context of the
existing postmaster logic is that the wait-for-ident state should
be a separate state of the protocol state machine.  That's doable
but rather tedious, which is why it hasn't got done yet (we have
a lot of higher-priority problems...)

It is a rather interesting thought to have the postmaster spawn a child
immediately to handle each authorization sequence, instead of doing so
only after it's completed the auth handshake.  That would confine the
ident problem to the particular client trying to authenticate, instead
of blocking everybody; it would prevent similar problems associated
with SSL and perhaps Kerberos; and it'd be a whole lot simpler than
the postmaster is now, because the auth code wouldn't have to fake
multithreading ability.  It'd be a significant rewrite though.
Want to work on it?
        regards, tom lane