Bug 92403 - RFE: cannot connect with UNIX username after upgrade to 3.23.56-1.72
RFE: cannot connect with UNIX username after upgrade to 3.23.56-1.72
Status: CLOSED UPSTREAM
Product: Red Hat Linux
Classification: Retired
Component: mysql (Show other bugs)
7.2
All Linux
medium Severity medium
: ---
: ---
Assigned To: Tom Lane
David Lawrence
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-06-05 16:11 EDT by Red Hat Production Operations
Modified: 2013-07-02 22:59 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-12-10 13:33:08 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Need Real Name 2003-06-05 16:11:49 EDT
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.
Comment 1 Patrick Macdonald 2003-06-05 16:46:00 EDT
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.
Comment 2 Need Real Name 2003-06-06 10:22:16 EDT
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";
    }
Comment 3 Need Real Name 2003-06-11 14:37:55 EDT
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?
Comment 4 Need Real Name 2003-06-18 15:40:22 EDT
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).
Comment 5 Tom Lane 2004-12-10 13:33:08 EST
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.

Note You need to log in before you can comment on or make changes to this bug.