Re: Logging of PAM Authentication Failure
От | Kyotaro HORIGUCHI |
---|---|
Тема | Re: Logging of PAM Authentication Failure |
Дата | |
Msg-id | 20130513.162545.168015968.horiguchi.kyotaro@lab.ntt.co.jp обсуждение исходный текст |
Ответ на | Re: Logging of PAM Authentication Failure (Amit Langote <amitlangote09@gmail.com>) |
Ответы |
Re: Logging of PAM Authentication Failure
|
Список | pgsql-hackers |
Hello, > > auth_failed() in src/backend/libpq/auth.c intentionally logs nothing for > > STATUS_EOF status (ie, client closed the connection without responding). > > But it looks like the PAM code path doesn't have a way to return that > > status code, even when pam_passwd_conv_proc() knows that that's what > > happened, and intentionally printed no log message itself (around line > > 1870 in HEAD). If there's another response code we could return through > > the PAM layer, this could be fixed, and I think it should be. > > So if I get this correctly, does this mean the only thing that needs > to be fixed is unnecessary logging or is there a problem with > authentication exchange itself in case of PAM? Also, when you say PAM > layer, is that pam_passwd_conv_proc() that needs to be able to return > an alternative status code? Following is the point server requests psql to send password when PAM is enabled. backend/libpq/auth.c:1861 > if (strlen(passwd) == 0) > { > /* > * Password wasn't passed to PAM the first time around - > * let's go ask the client to send a password, which we > * then stuff into PAM. > */ > sendAuthRequest(pam_port_cludge, AUTH_REQ_PASSWORD); > passwd = recv_password_packet(pam_port_cludge); > if (passwd == NULL) > { > /* > * Client didn't want to send password. We > * intentionally do not log anything about this. > */ > goto fail; ... > return PAM_CONV_ERR; This code seems to me expecting for psql to send password without closing current connnection.On the other hand psql does as follows. bin/psql/startup.c: 227 > pset.db = PQconnectdbParams(keywords, values, true); > free(keywords); > free(values); > > if (PQstatus(pset.db) == CONNECTION_BAD && > PQconnectionNeedsPassword(pset.db) && > password == NULL && > pset.getPassword != TRI_NO) > { > PQfinish(pset.db); > password = simple_prompt(password_prompt, 100, false); > new_pass = true; > } psql at once disconnects the current connection and reconnects with this new password, so pam_conv_err is observed in server. It seems to be a kind of protocol-mimatching. Client should'nt disconnect for password request or server should fit to what psql does. Is this wrong? regards, -- Kyotaro Horiguchi NTT Open Source Software Center
В списке pgsql-hackers по дате отправления: