Comment 4 for bug 1086795

> 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.