Thread

1. bug with identd autentication

   PostgreSQL Bugs List <pgsql-bugs@postgresql.org> — 2001-03-22T18:10:38Z

   Sbastien 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
   
   
   

2. Re: bug with identd autentication

   Tom Lane <tgl@sss.pgh.pa.us> — 2001-03-22T18:42:01Z

   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
   
   

3. Re: bug with identd autentication

   Tom Lane <tgl@sss.pgh.pa.us> — 2001-03-22T20:21:49Z

   =?iso-8859-1?Q?BLON_S=E9bastien?= <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