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: | 12286.985292509@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2001-03-22 20:28:56 | psql -c tends to core dump if interrupted |
Previous Message | Tom Lane | 2001-03-22 18:54:16 | Re: psql core dump on login |