Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1745217 - Permission is always denied when using non-plain password encryption
Summary: Permission is always denied when using non-plain password encryption
Keywords:
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: pam_mysql
Version: 33
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Paul P Komkoff Jr
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-08-24 00:31 UTC by Spike
Modified: 2021-04-18 05:00 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-05-26 14:37:37 UTC
Type: Bug
Embargoed:

Attachments (Terms of Use)
Verbose log output of pam_mysql (1.59 KB, text/plain)
2019-08-24 00:31 UTC, Spike 		no flags Details
View All

Description Spike 2019-08-24 00:31:52 UTC 
Created attachment 1607565 [details]
Verbose log output of pam_mysql

Description of problem:
Any password encryption method besides 0 (i.e. "plain") results in an authentication failure.

Version-Release number of selected component (if applicable):
pam_mysql-0.8.1-0.4.fc30.x86_64

How reproducible:
Always

Steps to Reproduce:
1. Create database, e.g.
CREATE database vpn_db;

CREATE TABLE tbl_user (
  username varchar(128),
  password varchar(128) NOT NULL,
  PRIMARY KEY (username)
);

INSERT INTO vpn_db.tbl_user (username, password) VALUES ('test', sha2('test', 512));

2. Create /etc/pam.d/mysql with the following content
auth       optional     pam_mysql.so config_file=/etc/pam_mysql.conf verbose=1
account    required     pam_mysql.so config_file=/etc/pam_mysql.conf verbose=1

3. Create /etc/pam_mysql.conf (change username/password/host/port accordingly)
users.host            = 127.0.0.1:3306
users.database        = vpn_db
users.db_user         = root
users.db_passwd       = my-secret-pw
users.table           = tbl_user
users.user_column     = tbl_user.username
users.password_column = tbl_user.password
users.password_crypt  = 8

Note: These match the default of the official mysql and maraidb containers, so one can quickly test this by running 
docker run --name some-mariadb --network=host -e MYSQL_ROOT_PASSWORD=my-secret-pw -d mariadb

4. Run pamtester:
echo "test" | pamtester -v mysql test authenticate

Actual results:
pamtester: invoking pam_start(mysql, test, ...)
pamtester: performing operation - authenticate
Password:pamtester: Permission denied

Expected results:
pamtester: invoking pam_start(mysql, test, ...)
pamtester: performing operation - authenticate
Password:pamtester: successfully authenticated


Additional info:
The result is the same for any password encryption method (tested md5, sha1, sha256, sha512). Authentications works as expected with plain text passwords though.
Updating to the latest commit (4f76d51671d3fcca495122e2404c746685563422) fixes this issue. A mock build for testing this is available here https://copr.fedorainfracloud.org/coprs/spike/pam-MySQL/
Comment 1 Spike 2019-09-05 13:24:04 UTC 
Pull request here: https://src.fedoraproject.org/rpms/pam_mysql/pull-request/1
Comment 2 customercare 2020-02-27 21:43:04 UTC 
The pamtester is complete rubbish..


[root@eve pam.d]# echo "nein" | pamtester -v su paula authenticate
pamtester: invoking pam_start(su, paula, ...)
pamtester: performing operation - authenticate
pamtester: successfully authenticated
[root@eve pam.d]# echo "23234nein" | pamtester -v su paula authenticate
pamtester: invoking pam_start(su, paula, ...)
pamtester: performing operation - authenticate
pamtester: successfully authenticated

... disabling pam_mysql entirely in su pamfile ...

[root@eve pam.d]# echo "23234nein" | pamtester -v su paula authenticate
pamtester: invoking pam_start(su, paula, ...)
pamtester: performing operation - authenticate
pamtester: successfully authenticated

and guess what.. the password is neither "nein" nor "23234nein" . I have no clue what pamtester tests, but it's pure fantasy.
Comment 3 customercare 2020-02-27 21:58:44 UTC 
btw: updating to the fc32 build of pam_mysql did not change anything.
Comment 4 customercare 2020-02-27 23:31:51 UTC 
BTW:

if pam.d/password-auth is changed to use pam_mysql, you get this:

Feb 28 00:27:01 eve sshd[13851]: pam_mysql - pam_sm_authenticate() called.
Feb 28 00:27:01 eve sshd[13851]: pam_mysql - pam_mysql_open_db() called.
Feb 28 00:27:01 eve sshd[13851]: pam_mysql - MySQL error (Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (13))
Feb 28 00:27:01 eve sshd[13851]: pam_mysql - pam_mysql_open_db() returning 5.
Feb 28 00:27:01 eve sshd[13851]: pam_mysql - pam_sm_authenticate() returning 9.
Feb 28 00:27:01 eve sshd[13851]: libnss-mysql: Connection to server 'localhost' failed: Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (13)
Feb 28 00:27:03 eve sshd[13851]: Failed password for invalid user paula from 127.0.0.1 port 60770 ssh2
Feb 28 00:27:32 eve sshd[13851]: Connection closed by invalid user paula 127.0.0.1 port 60770 [preauth]
Feb 28 00:27:32 eve sshd[13851]: pam_mysql - pam_mysql_release_ctx() called.
Feb 28 00:27:32 eve sshd[13851]: pam_mysql - pam_mysql_destroy_ctx() called.
Feb 28 00:27:32 eve sshd[13851]: pam_mysql - pam_mysql_close_db() called.

of course dbserver is running, because funny enough: pamtester (as user x, not root ) can access it ..

Feb 28 00:25:25 eve pamtester[13796]: pam_mysql - pam_mysql_sql_log() called.
Feb 28 00:25:25 eve pamtester[13796]: pam_mysql - pam_mysql_format_string() called
Feb 28 00:25:25 eve pamtester[13796]: pam_mysql - pam_mysql_quick_escape() called.
Feb 28 00:25:25 eve pamtester[13796]: pam_mysql - pam_mysql_quick_escape() called.
Feb 28 00:25:25 eve pamtester[13796]: pam_mysql - pam_mysql_quick_escape() called.
Feb 28 00:25:25 eve pamtester[13796]: pam_mysql - pam_mysql_quick_escape() called.
Feb 28 00:25:25 eve pamtester[13796]: pam_mysql - INSERT INTO log (message, user, host, rhost, pid, time) VALUES ('AUTHENTICATION SUCCESS (FIRST_PASS)', 'paula', '127.0.0.1', '(unknown)', '13796', NOW())
Feb 28 00:25:25 eve pamtester[13796]: pam_mysql - pam_mysql_sql_log() returning 0.
Feb 28 00:25:25 eve pamtester[13796]: pam_mysql - pam_sm_authenticate() returning 0.
Feb 28 00:25:27 eve pamtester[13796]: pam_mysql - pam_mysql_release_ctx() called.
Feb 28 00:25:27 eve pamtester[13796]: pam_mysql - pam_mysql_destroy_ctx() called.
Feb 28 00:25:27 eve pamtester[13796]: pam_mysql - pam_mysql_close_db() called.

so i revise my statement from rubbish to "it helps a tiny bit" :)
Comment 5 customercare 2020-02-28 16:06:26 UTC 
::::ARGS::::

FYI: SELinux disrupts access to mysql.sock for pam_mysql and nss.. 

Seperate BR filed.
Comment 6 Ben Cotton 2020-04-30 20:23:55 UTC 
This message is a reminder that Fedora 30 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 30 on 2020-05-26.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '30'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 30 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 7 customercare 2020-05-01 21:07:27 UTC 
Spike? Can you change it to f31?
Comment 8 Ben Cotton 2020-05-26 14:37:37 UTC 
Fedora 30 changed to end-of-life (EOL) status on 2020-05-26. Fedora 30 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.
Comment 9 Spike 2020-05-26 15:26:32 UTC 
Hi Paul,

This bug still exists on Fedora 32. I've updated the version accordingly. Since it's quite a simple fix and there's already a pull request, could you go ahead and merge that? If you think the patch needs some more work please let me know. Happy to make changes and resubmit.

Cheers!
Comment 10 Spike 2021-04-18 05:00:26 UTC 
Bug is still present on Fedora 33. I've updated the version accordingly.

The PR (https://src.fedoraproject.org/rpms/pam_mysql/pull-request/1) was also updated to reflect the latest upstream changes. Latest upstream commit is now 03a98ea508d9c7ee1ff71e735d76d9d99bd25c97
Note You need to log in before you can comment on or make changes to this bug.