Bug 92403
| Summary: | RFE: cannot connect with UNIX username after upgrade to 3.23.56-1.72 | ||
|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | Red Hat Production Operations <soc> |
| Component: | mysql | Assignee: | Tom Lane <tgl> |
| Status: | CLOSED UPSTREAM | QA Contact: | David Lawrence <dkl> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 7.2 | CC: | benl, hhorak |
| Target Milestone: | --- | Keywords: | FutureFeature |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Enhancement | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2004-12-10 18:33:08 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
There was some code movement in 3.23.56 to restrict the user name. This could be related to a security enhancement listed on http://www.mysql.com/doc/en/News-3.23.56.html. No one else has piped up about this but I'll check the mailing lists and code tomorrow. It looks like this is a result of the getlogin() call in libmysql.c:521 in
read_user_name(), which is called from mysql_real_connect().
In my case, I do not login directly as the user running the application, I login
and su to the user. The ordering of the getlogin() call in 3.23.56-1.72 reads
utmp first instead of doing the getpwuid(geteuid()), and picks up my username,
not the username that I have su'ed to. Since my user does not have access to
the database tables, this appears to be the root cause of the above connection
failure.
This is the code block in question:
if ((str=getlogin()) == NULL)
{
if ((skr=getpwuid(geteuid())) != NULL)
str=skr->pw_name;
else if (!(str=getenv("USER")) && !(str=getenv("LOGNAME")) &&
!(str=getenv("LOGIN")))
str="UNKNOWN_USER";
}
I have tried reproducing this bug but am unable to as it works for me on on the most recent release mysql-3.23.56-1.9 as well as on the previous version mysql-3.23.54a-3.71. The block of code you mentioned in the previous comment has also not changed between the two releases. This is not to say that it is not infact a problem, but perhaps you can specify more details that would aid me in reproducing it? Also, what was the older version of mysql that you upgraded to 3.23.56-1.72 from? I reverted back to 3.23.54a-3.72, 3.23.41-1, and 3.23.40-1, and I could not get
the previous behavior to return. At this point I am out of ideas as to what
caused this change in behavior.
I guess given the nature of this bug, perhaps it should be turned into an RFE
that this beahavior be made to work ('su -' to a user will use that user's
credentials when connecting to mysql rather than the tty owner).
My thought is that it is a bad idea for us to vary from the upstream behavior on points like this. I'd suggest filing a bug at www.mysql.com and seeing if you can persuade them that the behavior ought to change. |
Description of problem: Prior to installing the latest mysql errata, a mysql application could connect to the database using the UNIX username as the MySQL username. After installing the 3.23.56-1.72 errata, I have to create a .my.cnf with a "user=<username>" for the application to work. Version-Release number of selected component (if applicable): mysql-3.23.56-1.72 Steps to Reproduce: 1. Install an application that authenticates using the UNIX username 2. Run the application under the previous version of mysql 3. Upgrade mysql to 3.23.56-1.72 4. Run the application again, and watch it fail with: Error (1044): Access denied for user: '@localhost' to database <database> 5. Create a .my.cnf with user=<username> 6. Run the application a third time, and watch it succeed Actual results: After upgrading, this error was returned: Error (1044): Access denied for user: '@localhost' to database <database> By creating the .my.cnf file with user=<username>, the application was returned to normal functionality. Expected results: The application should have been able to connect to the database as the UNIX user without specifying a username to be used.