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

Re: bug with identd autentication

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: sb(at)nfrance(dot)com
Cc: pgsql-bugs(at)postgreSQL(dot)org
Subject: Re: bug with identd autentication
Date: 2001-03-22 20:21:49
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-bugs
=?iso-8859-1?Q?BLON_S=E9bastien?= <sebastien(dot)blon(at)nfrance(dot)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

In response to

pgsql-bugs by date

Next:From: Tom LaneDate: 2001-03-22 20:28:56
Subject: psql -c tends to core dump if interrupted
Previous:From: Tom LaneDate: 2001-03-22 18:54:16
Subject: Re: psql core dump on login

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