SET PASSWORD broken in 4.0.12 (-Max)

SET PASSWORD is badly broken. Users can no longer change their own
password thus:

root@abc:~# mysql -h dbserver -u mloftis -p mloftis
Enter password:
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 575149 to server version: 4.0.12-Max-log

Type 'help;' or '\h' for help. Type '\c' to clear the buffer.

mysql> set password = password('somenewpassword');
ERROR 1044: Access denied for user: 'mloftis@216.xxx.xxx.xxx' to database
'mysql'
mysql> \q
Bye
root@abc:~#


Any idea when/where/how this is broken? Soem new priv that must be granted
or what? I'm not about to give users much/any normal access to the mysql
database (they don't need it!!!)

TIA

--
MySQL Bugs Mailing List
For list archives: http://lists.mysql.com/bugs
To unsubscribe: http://lists.mysql.com/bugs?unsub=gcdmb-bugs@m.gmane.org

Re: SET PASSWORD broken in 4.0.12 (-Max)

Michael,

Michael Loftis wrote:
> SET PASSWORD is badly broken. Users can no longer change their own
> password thus:
>
> root@abc:~# mysql -h dbserver -u mloftis -p mloftis
> Enter password:
> Welcome to the MySQL monitor. Commands end with ; or \g.
> Your MySQL connection id is 575149 to server version: 4.0.12-Max-log
>
> Type 'help;' or '\h' for help. Type '\c' to clear the buffer.
>
> mysql> set password = password('somenewpassword');
> ERROR 1044: Access denied for user: 'mloftis@216.xxx.xxx.xxx' to
> database 'mysql'
> mysql> \q
> Bye
> root@abc:~#


I repeated your steps and was able to change password successflly.

Can you provide more info?
What OS?
How did you installed MySQL? From binary distribution or RPM?

>
> Any idea when/where/how this is broken? Soem new priv that must be
> granted or what? I'm not about to give users much/any normal access to
> the mysql database (they don't need it!!!)
>
> TIA

Best regards

--
For technical support contracts, visit https://order.mysql.com/?ref=msal
__ ___ ___ ____ __
/ |/ /_ __/ __/ __ \/ / Mr. Alexander Keremidarski
/ /|_/ / // /\ \/ /_/ / /__ MySQL AB, Full-Time Developer
/_/ /_/\_, /___/\___\_\___/ Sofia, Bulgaria
<___/ www.mysql.com




--
MySQL Bugs Mailing List
For list archives: http://lists.mysql.com/bugs
To unsubscribe: http://lists.mysql.com/bugs?unsub=gcdmb-bugs@m.gmane.org

Re: SET PASSWORD broken in 4.0.12 (-Max)

--On Monday, April 21, 2003 2:28 AM +0300 Alexander Keremidarski
wrote:

> I repeated your steps and was able to change password successflly.
>
> Can you provide more info?
> What OS?
> How did you installed MySQL? From binary distribution or RPM?

RH7.2, RPM Based install. The only possible wrinkle I could think of is
we're stillusing the 3.23 client but that shouldn't make a difference (it's
all SQL being passed back to the server). Our .user table lists the users
without any privileges at all (all N's), in the .db table we grant rights
to the users specific database (the specific list is select, insert,
update, delete, create, drop, alter, LOCK TABLES, index) and nothing more.
Below is an output of the version information.

root@abc:~# mysqladmin -h dbserver -p version
Enter password:
mysqladmin Ver 8.23 Distrib 3.23.56, for pc-linux on i686
Copyright (C) 2000 MySQL AB & MySQL Finland AB & TCX DataKonsult AB
This software comes with ABSOLUTELY NO WARRANTY. This is free software,
and you are welcome to modify and redistribute it under the GPL license

Server version 4.0.12-Max-log
Protocol version 10
Connection dbserver via TCP/IP
TCP port 3306
Uptime: 1 day 16 hours 41 min 57 sec

Threads: 11 Questions: 26486109 Slow queries: 1688 Opens: 437929 Flush
tables: 1 Open tables: 512 Queries per second avg: 180.772
root@abc:~#



--
MySQL Bugs Mailing List
For list archives: http://lists.mysql.com/bugs
To unsubscribe: http://lists.mysql.com/bugs?unsub=gcdmb-bugs@m.gmane.org

Re: SET PASSWORD broken in 4.0.12 (-Max)

Michael,

Michael Loftis wrote:


> RH7.2, RPM Based install. The only possible wrinkle I could think of is
> we're stillusing the 3.23 client but that shouldn't make a difference
> (it's all SQL being passed back to the server). Our .user table lists
> the users without any privileges at all (all N's), in the .db table we
> grant rights to the users specific database (the specific list is
> select, insert, update, delete, create, drop, alter, LOCK TABLES, index)
> and nothing more. Below is an output of the version information.

I tested this too. Connecting with 3.23 client to 4.0 server I was able to change
password without problem. You are right that it should not depend on client at all.

I tested it with 4.0.12 and 4.0.12 Max fropm RPMs as well as with 4.0.13 from
source tree.

Best regards

--
For technical support contracts, visit https://order.mysql.com/?ref=msal
__ ___ ___ ____ __
/ |/ /_ __/ __/ __ \/ / Mr. Alexander Keremidarski
/ /|_/ / // /\ \/ /_/ / /__ MySQL AB, Full-Time Developer
/_/ /_/\_, /___/\___\_\___/ Sofia, Bulgaria
<___/ www.mysql.com




--
MySQL Bugs Mailing List
For list archives: http://lists.mysql.com/bugs
To unsubscribe: http://lists.mysql.com/bugs?unsub=gcdmb-bugs@m.gmane.org

Re: SET PASSWORD broken in 4.0.12 (-Max)

The only other thing I can think of is that there's a blank user with %
host that has a password and no access at all, used to prevent any
anonymous access. Could that be it?

What are the exact steps/requirements for set password to work? It should
be bypassing *ALL* permissions checks, just operating on the current user.

This is totally and completely reproducible and from what I can tell from
the documentation set password should NEVER give access denied. So
obviously you guys have an undocumented condition in 4.0 that has to be met
in order for SET PASSWORD to succeed. I really don't have time right now
to get into the source code and find this and document it.

If anyone can think of anything to try I'd be very appreciative.



--On Monday, April 21, 2003 2:51 AM +0300 Alexander Keremidarski
wrote:

> Michael,
>
> Michael Loftis wrote:
>
>
>> RH7.2, RPM Based install. The only possible wrinkle I could think of is
>> we're stillusing the 3.23 client but that shouldn't make a difference
>> (it's all SQL being passed back to the server). Our .user table lists
>> the users without any privileges at all (all N's), in the .db table we
>> grant rights to the users specific database (the specific list is
>> select, insert, update, delete, create, drop, alter, LOCK TABLES, index)
>> and nothing more. Below is an output of the version information.
>
> I tested this too. Connecting with 3.23 client to 4.0 server I was able
> to change password without problem. You are right that it should not
> depend on client at all.
>
> I tested it with 4.0.12 and 4.0.12 Max fropm RPMs as well as with 4.0.13
> from source tree.
>
> Best regards
>
> --
> For technical support contracts, visit https://order.mysql.com/?ref=msal
> __ ___ ___ ____ __
> / |/ /_ __/ __/ __ \/ / Mr. Alexander Keremidarski
> / /|_/ / // /\ \/ /_/ / /__ MySQL AB, Full-Time
> Developer
> /_/ /_/\_, /___/\___\_\___/ Sofia, Bulgaria
> <___/ www.mysql.com
>
>
>
>



--
MySQL Bugs Mailing List
For list archives: http://lists.mysql.com/bugs
To unsubscribe: http://lists.mysql.com/bugs?unsub=gcdmb-bugs@m.gmane.org

Re: SET PASSWORD broken in 4.0.12 (-Max) Found the bug in sql/sql_acl.cc:1007 -- check_change_passwo

And here it is in a nutshell folks. Update access to mysql table is
apparently required.

Why is this the case? That code seems to need to be yanked atleast for the
case of change_password/SET PASSWORD.

I think what was meant to be done is to pass through when user was equal to
the current user, but when it wasn't to perform the access check. The if
statement reads if we're not a slave AND the user is equal, OR the host
matches up we do a check on the access? That last part makes very little
sense...I need to see what my_strcasecmp does, but I've a suspicion that
this code doesn't work right possibly because we use %.modwest.com as the
hostname, and the error I'm getting spits back the IP at me. So maybe
thd->host is getting NULLed wrongly as well.

In any event this code is BROKEN! Need to take a serious look at that if
statement, or on what host SET PASSWORD will pass in. I'm thinking our
problem might be related to getting an IP passed in there instead of a
hostname or vice-versa thus making host and thd->host mismatch? I need to
dig deeper, because perhaps the real evil is further up in how/where the
grammar calls for SET PASSWORD and gets the host that's eventually passed
to check_change_password.

It boils down to this code in

/*********************************************************** ***************
***
Change password for the user if it's not an anonymous user
Note: This should write the error directly to the client!
************************************************************ ***************
**/

/*
Check if the user is allowed to change password

SYNOPSIS:
check_change_password()
thd THD
host hostname for the user
user user name

RETURN VALUE
0 OK
1 ERROR ; In this case the error is sent to the client.
*/

bool check_change_password(THD *thd, const char *host, const char *user)
{
if (!initialized)
{
send_error(&thd->net, ER_PASSWORD_NOT_ALLOWED); /* purecov: inspected */
return(1); /* purecov: inspected */
}
if (!thd->slave_thread &&
(strcmp(thd->user,user) ||
my_strcasecmp(host,thd->host ? thd->host : thd->ip)))
{
if (check_access(thd, UPDATE_ACL, "mysql",0,1))
return(1);
}
if (!thd->slave_thread && !thd->user[0])
{
send_error(&thd->net, ER_PASSWORD_ANONYMOUS_USER);
return(1);
}
return(0);
}

--On Monday, April 21, 2003 2:51 AM +0300 Alexander Keremidarski
wrote:

> Michael,
>
> Michael Loftis wrote:
>
>
>> RH7.2, RPM Based install. The only possible wrinkle I could think of is
>> we're stillusing the 3.23 client but that shouldn't make a difference
>> (it's all SQL being passed back to the server). Our .user table lists
>> the users without any privileges at all (all N's), in the .db table we
>> grant rights to the users specific database (the specific list is
>> select, insert, update, delete, create, drop, alter, LOCK TABLES, index)
>> and nothing more. Below is an output of the version information.
>
> I tested this too. Connecting with 3.23 client to 4.0 server I was able
> to change password without problem. You are right that it should not
> depend on client at all.
>
> I tested it with 4.0.12 and 4.0.12 Max fropm RPMs as well as with 4.0.13
> from source tree.
>
> Best regards
>
> --
> For technical support contracts, visit https://order.mysql.com/?ref=msal
> __ ___ ___ ____ __
> / |/ /_ __/ __/ __ \/ / Mr. Alexander Keremidarski
> / /|_/ / // /\ \/ /_/ / /__ MySQL AB, Full-Time
> Developer
> /_/ /_/\_, /___/\___\_\___/ Sofia, Bulgaria
> <___/ www.mysql.com
>
>
>
>



--
Michael Loftis
Modwest Sr. Systems Administrator
Powerful, Affordable Web Hosting

--
MySQL Bugs Mailing List
For list archives: http://lists.mysql.com/bugs
To unsubscribe: http://lists.mysql.com/bugs?unsub=gcdmb-bugs@m.gmane.org

Re: SET PASSWORD broken in 4.0.12 (-Max) Found the bug in sql/sql_acl.cc:1007 -- check_change_passwo

Michael Loftis writes:
> And here it is in a nutshell folks. Update access to mysql table is
> apparently required.
>
> Why is this the case? That code seems to need to be yanked atleast for the
> case of change_password/SET PASSWORD.
>
>

[skip]

>
>
> --
> Michael Loftis
> Modwest Sr. Systems Administrator
> Powerful, Affordable Web Hosting

Hi!

UPDATE privilege on mysql db is required ONLY if password is changed
for some other user.

Otherwise there is no such requirement.

--

Regards,

--
For technical support contracts, go to https://order.mysql.com/?ref=msmi
__ ___ ___ ____ __
/ |/ /_ __/ __/ __ \/ / Mr. Sinisa Milivojevic
/ /|_/ / // /\ \/ /_/ / /__ MySQL AB, FullTime Developer
/_/ /_/\_, /___/\___\_\___/ Larnaca, Cyprus
<___/ www.mysql.com


--
MySQL Bugs Mailing List
For list archives: http://lists.mysql.com/bugs
To unsubscribe: http://lists.mysql.com/bugs?unsub=gcdmb-bugs@m.gmane.org

Re: SET PASSWORD broken in 4.0.12 (-Max) Found the bug in sql/sql_acl.cc:1007 -- check_change_passwo

Look at the code though. The actual case is if the user or the host
doesn't match up. and SET PASSWORD is giving it user->host.str which
appears to be the IP address as a string.

It's using a different host name than the authentication system is using
(because we can obviously login fine). The other thing that makes me
wonder is does my_strcasecmp() do % wildcarding? If not that breaks this
too.

--On Monday, April 21, 2003 2:57 PM +0300 Sinisa Milivojevic
wrote:

> Michael Loftis writes:
>> And here it is in a nutshell folks. Update access to mysql table is
>> apparently required.
>>
>> Why is this the case? That code seems to need to be yanked atleast for
>> the case of change_password/SET PASSWORD.
>>
>>
>
> [skip]
>
>>
>>
>> --
>> Michael Loftis
>> Modwest Sr. Systems Administrator
>> Powerful, Affordable Web Hosting
>
> Hi!
>
> UPDATE privilege on mysql db is required ONLY if password is changed
> for some other user.
>
> Otherwise there is no such requirement.
>
> --
>
> Regards,
>
> --
> For technical support contracts, go to https://order.mysql.com/?ref=msmi
> __ ___ ___ ____ __
> / |/ /_ __/ __/ __ \/ / Mr. Sinisa Milivojevic
> / /|_/ / // /\ \/ /_/ / /__ MySQL AB, FullTime Developer
> /_/ /_/\_, /___/\___\_\___/ Larnaca, Cyprus
> <___/ www.mysql.com
>
>



--
Michael Loftis
Modwest Sr. Systems Administrator
Powerful, Affordable Web Hosting

--
MySQL Bugs Mailing List
For list archives: http://lists.mysql.com/bugs
To unsubscribe: http://lists.mysql.com/bugs?unsub=gcdmb-bugs@m.gmane.org

Re: SET PASSWORD broken in 4.0.12 (-Max) Found the bug in sql/sql_acl.cc:1007 -- check_change_passwo

I've also just tried it with user table entries for my full IP, my
wildcarded IP as well. I always get teh denied message even when I use the
uname@IP that it gives in the error message. Yes I'm using flush
privileges, I even got so paranoid as to fully remove the other entries and
use entirely different passwords, all to no avail.

--On Monday, April 21, 2003 11:15 AM -0700 Michael Loftis
wrote:

> Look at the code though. The actual case is if the user or the host
> doesn't match up. and SET PASSWORD is giving it user->host.str which
> appears to be the IP address as a string.
>
> It's using a different host name than the authentication system is using
> (because we can obviously login fine). The other thing that makes me
> wonder is does my_strcasecmp() do % wildcarding? If not that breaks this
> too.
>
> --On Monday, April 21, 2003 2:57 PM +0300 Sinisa Milivojevic
> wrote:
>
>> Michael Loftis writes:
>>> And here it is in a nutshell folks. Update access to mysql table is
>>> apparently required.
>>>
>>> Why is this the case? That code seems to need to be yanked atleast for
>>> the case of change_password/SET PASSWORD.
>>>
>>>
>>
>> [skip]
>>
>>>
>>>
>>> --
>>> Michael Loftis
>>> Modwest Sr. Systems Administrator
>>> Powerful, Affordable Web Hosting
>>
>> Hi!
>>
>> UPDATE privilege on mysql db is required ONLY if password is changed
>> for some other user.
>>
>> Otherwise there is no such requirement.
>>
>> --
>>
>> Regards,
>>
>> --
>> For technical support contracts, go to https://order.mysql.com/?ref=msmi
>> __ ___ ___ ____ __
>> / |/ /_ __/ __/ __ \/ / Mr. Sinisa Milivojevic
>> / /|_/ / // /\ \/ /_/ / /__ MySQL AB, FullTime Developer
>> /_/ /_/\_, /___/\___\_\___/ Larnaca, Cyprus
>> <___/ www.mysql.com
>>
>>
>
>
>
> --
> Michael Loftis
> Modwest Sr. Systems Administrator
> Powerful, Affordable Web Hosting
>
> --
> MySQL Bugs Mailing List
> For list archives: http://lists.mysql.com/bugs
> To unsubscribe: http://lists.mysql.com/bugs?unsub=mloftis@modwest.com
>
>



--
Michael Loftis
Modwest Sr. Systems Administrator
Powerful, Affordable Web Hosting

--
MySQL Bugs Mailing List
For list archives: http://lists.mysql.com/bugs
To unsubscribe: http://lists.mysql.com/bugs?unsub=gcdmb-bugs@m.gmane.org

Re: SET PASSWORD broken in 4.0.12 (-Max) Found the bug in sql/sql_acl.cc:1007 -- check_change_passwo

Michael Loftis writes:
> Look at the code though. The actual case is if the user or the host
> doesn't match up. and SET PASSWORD is giving it user->host.str which
> appears to be the IP address as a string.
>
> It's using a different host name than the authentication system is using
> (because we can obviously login fine). The other thing that makes me
> wonder is does my_strcasecmp() do % wildcarding? If not that breaks this
> too.
>

In short, you were right.

This is in course of fixing. This is the interim fix for 4.0.13:

===== sql/sql_acl.cc 1.92 vs edited =====
*** /tmp/sql_acl.cc-1.92-4025 Wed Apr 16 13:05:23 2003
--- edited/sql/sql_acl.cc Mon Apr 21 22:11:15 2003
***************
*** 1029,1035 ****
}
if (!thd->slave_thread &&
(strcmp(thd->user,user) ||
! my_strcasecmp(host,thd->host ? thd->host : thd->ip)))
{
if (check_access(thd, UPDATE_ACL, "mysql",0,1))
return(1);
--- 1029,1035 ----
}
if (!thd->slave_thread &&
(strcmp(thd->user,user) ||
! my_strcasecmp(host,thd->host_or_ip)))
{
if (check_access(thd, UPDATE_ACL, "mysql",0,1))
return(1);
***************
*** 1061,1078 ****
bool change_password(THD *thd, const char *host, const char *user,
char *new_password)
{
! uint length=0;
DBUG_ENTER("change_password");
DBUG_PRINT("enter",("host: '%s' user: '%s' new_password: '%s'",
host,user,new_password));
DBUG_ASSERT(host != 0); // Ensured by parent

- if (check_change_password(thd, host, user))
- DBUG_RETURN(1);
-
/* password should always be 0 or 16 chars; simple hack to avoid cracking */
- length=(uint) strlen(new_password);
- new_password[length & 16]=0;

VOID(pthread_mutex_lock(&acl_cache->lock));
ACL_USER *acl_user;
--- 1061,1073 ----
bool change_password(THD *thd, const char *host, const char *user,
char *new_password)
{
! char *pass_buff;
DBUG_ENTER("change_password");
DBUG_PRINT("enter",("host: '%s' user: '%s' new_password: '%s'",
host,user,new_password));
DBUG_ASSERT(host != 0); // Ensured by parent

/* password should always be 0 or 16 chars; simple hack to avoid cracking */

VOID(pthread_mutex_lock(&acl_cache->lock));
ACL_USER *acl_user;
***************
*** 1082,1097 ****
VOID(pthread_mutex_unlock(&acl_cache->lock));
DBUG_RETURN(1);
}
if (update_user_table(thd,
acl_user->host.hostname ? acl_user->host.hostname : "",
acl_user->user ? acl_user->user : "",
! new_password))
{
VOID(pthread_mutex_unlock(&acl_cache->lock)); /* purecov: deadcode */
send_error(&thd->net,0); /* purecov: deadcode */
DBUG_RETURN(1); /* purecov: deadcode */
}
! get_salt_from_password(acl_user->salt,new_password);
if (!new_password[0])
acl_user->password=0;
else
--- 1077,1101 ----
VOID(pthread_mutex_unlock(&acl_cache->lock));
DBUG_RETURN(1);
}
+
+ if (new_password[0])
+ {
+ pass_buff=(char*) sql_alloc(HASH_PASSWORD_LENGTH+1);
+ if (pass_buff)
+ make_scrambled_password(pass_buff,new_password);
+ else
+ DBUG_RETURN(1);
+ }
if (update_user_table(thd,
acl_user->host.hostname ? acl_user->host.hostname : "",
acl_user->user ? acl_user->user : "",
! new_password[0] ? pass_buff : ""))
{
VOID(pthread_mutex_unlock(&acl_cache->lock)); /* purecov: deadcode */
send_error(&thd->net,0); /* purecov: deadcode */
DBUG_RETURN(1); /* purecov: deadcode */
}
! get_salt_from_password(acl_user->salt,new_password[0] ? pass_buff : "");
if (!new_password[0])
acl_user->password=0;
else


--

Regards,

--
For technical support contracts, go to https://order.mysql.com/?ref=msmi
__ ___ ___ ____ __
/ |/ /_ __/ __/ __ \/ / Mr. Sinisa Milivojevic
/ /|_/ / // /\ \/ /_/ / /__ MySQL AB, FullTime Developer
/_/ /_/\_, /___/\___\_\___/ Larnaca, Cyprus
<___/ www.mysql.com


--
MySQL Bugs Mailing List
For list archives: http://lists.mysql.com/bugs
To unsubscribe: http://lists.mysql.com/bugs?unsub=gcdmb-bugs@m.gmane.org

Re: SET PASSWORD broken in 4.0.12 (-Max) Found the bug in sql/sql_acl.cc:1007 -- check_change_passwo

I've tried also with '' and '%' now as the Host. Nothing works. Could
this be related somehow to replication as we're using that (both servers
are 4.0.12)? or to the safe-show-database option?

--On Monday, April 21, 2003 11:15 AM -0700 Michael Loftis
wrote:

> Look at the code though. The actual case is if the user or the host
> doesn't match up. and SET PASSWORD is giving it user->host.str which
> appears to be the IP address as a string.
>
> It's using a different host name than the authentication system is using
> (because we can obviously login fine). The other thing that makes me
> wonder is does my_strcasecmp() do % wildcarding? If not that breaks this
> too.
>
> --On Monday, April 21, 2003 2:57 PM +0300 Sinisa Milivojevic
> wrote:
>
>> Michael Loftis writes:
>>> And here it is in a nutshell folks. Update access to mysql table is
>>> apparently required.
>>>
>>> Why is this the case? That code seems to need to be yanked atleast for
>>> the case of change_password/SET PASSWORD.
>>>
>>>
>>
>> [skip]
>>
>>>
>>>
>>> --
>>> Michael Loftis
>>> Modwest Sr. Systems Administrator
>>> Powerful, Affordable Web Hosting
>>
>> Hi!
>>
>> UPDATE privilege on mysql db is required ONLY if password is changed
>> for some other user.
>>
>> Otherwise there is no such requirement.
>>
>> --
>>
>> Regards,
>>
>> --
>> For technical support contracts, go to https://order.mysql.com/?ref=msmi
>> __ ___ ___ ____ __
>> / |/ /_ __/ __/ __ \/ / Mr. Sinisa Milivojevic
>> / /|_/ / // /\ \/ /_/ / /__ MySQL AB, FullTime Developer
>> /_/ /_/\_, /___/\___\_\___/ Larnaca, Cyprus
>> <___/ www.mysql.com
>>
>>
>
>
>
> --
> Michael Loftis
> Modwest Sr. Systems Administrator
> Powerful, Affordable Web Hosting
>
> --
> MySQL Bugs Mailing List
> For list archives: http://lists.mysql.com/bugs
> To unsubscribe: http://lists.mysql.com/bugs?unsub=mloftis@modwest.com
>
>



--
Michael Loftis
Modwest Sr. Systems Administrator
Powerful, Affordable Web Hosting

--
MySQL Bugs Mailing List
For list archives: http://lists.mysql.com/bugs
To unsubscribe: http://lists.mysql.com/bugs?unsub=gcdmb-bugs@m.gmane.org

Re: SET PASSWORD broken in 4.0.12 (-Max) Found the bug in sql/sql_acl.cc:1007 -- check_change_passwo

Well closer anyway. Now instead of 1044 (or whatever Access Denied is) I
get ->

ERROR 1133: Can't find any matching row in the user table

This whole thing goes back to authorization/logging in using a different
check method than the change_password method. They should be doing the
same thing here. Now it passes the check properly, but it still needs to
get the (most specific?) entry that matches and then update that. Better
still the authentication process should leave this information somewhere in
the user object that SET PASSWORD uses initially and this information could
then also be available to the change_password mechanism. Not sure how this
should/could/would be handled in the event that an intervening session
revoked or otherwise completely removed the mysql.user entry we want to
touch.

In any event this is much closer as the check is succeeding like it should
and we don't appear to have introduced any other bug(s).

The call to update_user_table in change_password needs to know/use/update
the same row that we used for authentication. Likewise
check_change_password should also be using this information.

Perhaps check_change_password needs to use find_acl_user? Or is this error
being tossed by find_acl_user? I'm turning on debugging and recompiling.
It just still is obvious that the authentication mechanism is using
something else than what this password change mechanism is using.

--On Monday, April 21, 2003 10:17 PM +0300 Sinisa Milivojevic
wrote:

> Michael Loftis writes:
>> Look at the code though. The actual case is if the user or the host
>> doesn't match up. and SET PASSWORD is giving it user->host.str which
>> appears to be the IP address as a string.
>>
>> It's using a different host name than the authentication system is using
>> (because we can obviously login fine). The other thing that makes me
>> wonder is does my_strcasecmp() do % wildcarding? If not that breaks
>> this too.
>>
>
> In short, you were right.
>
> This is in course of fixing. This is the interim fix for 4.0.13:
>
> ===== sql/sql_acl.cc 1.92 vs edited =====
> *** /tmp/sql_acl.cc-1.92-4025 Wed Apr 16 13:05:23 2003
> --- edited/sql/sql_acl.cc Mon Apr 21 22:11:15 2003
> ***************
> *** 1029,1035 ****
> }
> if (!thd->slave_thread &&
> (strcmp(thd->user,user) ||
> ! my_strcasecmp(host,thd->host ? thd->host : thd->ip)))
> {
> if (check_access(thd, UPDATE_ACL, "mysql",0,1))
> return(1);
> --- 1029,1035 ----
> }
> if (!thd->slave_thread &&
> (strcmp(thd->user,user) ||
> ! my_strcasecmp(host,thd->host_or_ip)))
> {
> if (check_access(thd, UPDATE_ACL, "mysql",0,1))
> return(1);
> ***************
> *** 1061,1078 ****
> bool change_password(THD *thd, const char *host, const char *user,
> char *new_password)
> {
> ! uint length=0;
> DBUG_ENTER("change_password");
> DBUG_PRINT("enter",("host: '%s' user: '%s' new_password: '%s'",
> host,user,new_password));
> DBUG_ASSERT(host != 0); // Ensured by parent
>
> - if (check_change_password(thd, host, user))
> - DBUG_RETURN(1);
> -
> /* password should always be 0 or 16 chars; simple hack to avoid
> cracking */ - length=(uint) strlen(new_password);
> - new_password[length & 16]=0;
>
> VOID(pthread_mutex_lock(&acl_cache->lock));
> ACL_USER *acl_user;
> --- 1061,1073 ----
> bool change_password(THD *thd, const char *host, const char *user,
> char *new_password)
> {
> ! char *pass_buff;
> DBUG_ENTER("change_password");
> DBUG_PRINT("enter",("host: '%s' user: '%s' new_password: '%s'",
> host,user,new_password));
> DBUG_ASSERT(host != 0); // Ensured by parent
>
> /* password should always be 0 or 16 chars; simple hack to avoid
> cracking */
> VOID(pthread_mutex_lock(&acl_cache->lock));
> ACL_USER *acl_user;
> ***************
> *** 1082,1097 ****
> VOID(pthread_mutex_unlock(&acl_cache->lock));
> DBUG_RETURN(1);
> }
> if (update_user_table(thd,
> acl_user->host.hostname ? acl_user->host.hostname : "",
> acl_user->user ? acl_user->user : "",
> ! new_password))
> {
> VOID(pthread_mutex_unlock(&acl_cache->lock)); /* purecov: deadcode
> */ send_error(&thd->net,0); /* purecov: deadcode */
> DBUG_RETURN(1); /* purecov: deadcode */
> }
> ! get_salt_from_password(acl_user->salt,new_password);
> if (!new_password[0])
> acl_user->password=0;
> else
> --- 1077,1101 ----
> VOID(pthread_mutex_unlock(&acl_cache->lock));
> DBUG_RETURN(1);
> }
> +
> + if (new_password[0])
> + {
> + pass_buff=(char*) sql_alloc(HASH_PASSWORD_LENGTH+1);
> + if (pass_buff)
> + make_scrambled_password(pass_buff,new_password);
> + else
> + DBUG_RETURN(1);
> + }
> if (update_user_table(thd,
> acl_user->host.hostname ? acl_user->host.hostname : "",
> acl_user->user ? acl_user->user : "",
> ! new_password[0] ? pass_buff : ""))
> {
> VOID(pthread_mutex_unlock(&acl_cache->lock)); /* purecov: deadcode
> */ send_error(&thd->net,0); /* purecov: deadcode */
> DBUG_RETURN(1); /* purecov: deadcode */
> }
> ! get_salt_from_password(acl_user->salt,new_password[0] ? pass_buff :
> ""); if (!new_password[0])
> acl_user->password=0;
> else
>
>
> --
>
> Regards,
>
> --
> For technical support contracts, go to https://order.mysql.com/?ref=msmi
> __ ___ ___ ____ __
> / |/ /_ __/ __/ __ \/ / Mr. Sinisa Milivojevic
> / /|_/ / // /\ \/ /_/ / /__ MySQL AB, FullTime Developer
> /_/ /_/\_, /___/\___\_\___/ Larnaca, Cyprus
> <___/ www.mysql.com
>
>



--
Michael Loftis
Modwest Sr. Systems Administrator
Powerful, Affordable Web Hosting

--
MySQL Bugs Mailing List
For list archives: http://lists.mysql.com/bugs
To unsubscribe: http://lists.mysql.com/bugs?unsub=gcdmb-bugs@m.gmane.org

Re: SET PASSWORD broken in 4.0.12 (-Max) Found the bug in sql/sql_acl.cc:1007 -- check_change_passwo

Michael Loftis writes:
> Well closer anyway. Now instead of 1044 (or whatever Access Denied is) I
> get ->
>
> ERROR 1133: Can't find any matching row in the user table
>
> This whole thing goes back to authorization/logging in using a different
> check method than the change_password method. They should be doing the
> same thing here. Now it passes the check properly, but it still needs to
> get the (most specific?) entry that matches and then update that. Better
> still the authentication process should leave this information somewhere in
> the user object that SET PASSWORD uses initially and this information could
> then also be available to the change_password mechanism. Not sure how this
> should/could/would be handled in the event that an intervening session
> revoked or otherwise completely removed the mysql.user entry we want to
> touch.
>
> In any event this is much closer as the check is succeeding like it should
> and we don't appear to have introduced any other bug(s).
>
> The call to update_user_table in change_password needs to know/use/update
> the same row that we used for authentication. Likewise
> check_change_password should also be using this information.
>
> Perhaps check_change_password needs to use find_acl_user? Or is this error
> being tossed by find_acl_user? I'm turning on debugging and recompiling.
> It just still is obvious that the authentication mechanism is using
> something else than what this password change mechanism is using.


No,

patch that I have posted is not OK.

I revised it and made a new one later.

It will come in 4.0.13, which should be out next week.


--

Regards,

--
For technical support contracts, go to https://order.mysql.com/?ref=msmi
__ ___ ___ ____ __
/ |/ /_ __/ __/ __ \/ / Mr. Sinisa Milivojevic
/ /|_/ / // /\ \/ /_/ / /__ MySQL AB, FullTime Developer
/_/ /_/\_, /___/\___\_\___/ Larnaca, Cyprus
<___/ www.mysql.com


--
MySQL Bugs Mailing List
For list archives: http://lists.mysql.com/bugs
To unsubscribe: http://lists.mysql.com/bugs?unsub=gcdmb-bugs@m.gmane.org