unix_chkpwd fails with Percona pam plugin

https://gist.github.com/b137adf6105afc0ba83c is where the PAM authentication fails.

Since, salt is NULL,

========
 helper_log_err(LOG_WARNING, "check pass; user unknown");
retval = PAM_USER_UNKNOWN;
============

and

=============================

 retval = helper_verify_password(user, pass, nullok);

 memset(pass, '\0', MAXPASS); /* clear memory of the password */

 /* return pass or fail */

 if (retval != PAM_SUCCESS) {
  if (!nullok || !blankpass) {
   /* no need to log blank pass test */
#ifdef HAVE_LIBAUDIT
   if (getuid() != 0)
    _audit_log(AUDIT_USER_AUTH, user, PAM_AUTH_ERR);
#endif
   helper_log_err(LOG_NOTICE, "password check failed for user (%s)", user);
  }
  return PAM_AUTH_ERR;
 } else {
         if (getuid() != 0) {
#ifdef HAVE_LIBAUDIT
   return _audit_log(AUDIT_USER_AUTH, user, PAM_SUCCESS);
#else
          return PAM_SUCCESS;
#endif
         }
  return PAM_SUCCESS;
 }

=======================================

hence, the message "password check failed for user ..." printed

 To summarize the problem -- "the one talking to PAM is not the same uid as the one who is get authenticated", hence, the PAM authentication should take place on the client side (may be in the client plugin).

Raghu,

Regarding the last comment "...the PAM authentication should take place on the client side...". This approach breaks security totally. Anyone could write client which will always authenticate successfully on my server in this case. This is not what I may want from PAM authentication plugin when I use it.

> Regarding the last comment "...the PAM authentication should
> take place on the client side...". This approach breaks
> security totally. Anyone could write client which will always
> authenticate successfully on my server in this case. This is
> not what I may want from PAM authentication plugin when I use
> it.

Sergei,

1)

Isn't that the point of having pam_unix in PAM plugin stack? I
mean if I have authenticated as X user, I don't need any more
authentication (other than knowing password for X account) for
logging into mysql server as X user. Isn't that the purpose and
the role played by the plugin? (ie. when pam_unix is used)

Regarding "Anyone could write client which will always authenticate successfully on my server in this case.", they can only if they authenticate as the 'X' user.

I think that may be root cause why unix_chkpwd is not working, it
checks the euid of the user and since the tuple (euid, username)
doesn't match, it returns 'user unknown' (because getspnam
returns empty).

The gist is that if I can do sudo -u anotheruser bash and run
commands, then I should be able to do mysql -u anotheruser when
logged in as that user.

What I see happening now is that MySQL server acts as a middleman

 pam_unix/shadow <---> MySQL server <--------> MySQL client

 I don't think PAM can work like that (or may, *needs to be
 checked* (I am not sure RUSER vs USER makes difference here)).
 The other pam_unix + unix_chkpwd users like xlock run as the
 authenticating user itself.

 2) Secondary to this bug, another reason why I (and others have
 echoed it) think doing in client may help is that currently
 password is sent clear-text in the ensuing communication for
 authentication. So, fixing the above, may fix this as well.

Quick correction in the above,
>I mean if I have authenticated as X user, I don't need any more
>authentication (other than knowing password for X account) for
>logging into mysql server as X user

I have seen that I can authenticate to mysql/pam as Y user when logged in as X user, with Y user's password (currently only possible if Y == 'mysql' ; which is essentially equivalent to authenticating as Y user). However, if I am already logged in as Y user and try to authenticate to mysql as Y user, it will still ask for Y user's password which is fine.