MySQL Preacher » grants

Recovering a MySQL `root` password – Three solutions

Darren Cassar — Mon, 21 Mar 2011 19:00:58 +0000

Three ways to recover a root user password:

The order of solutions here under gets more creative on the way down :)

1. obviously, before starting messing around check my.cnf or scripts for passwords entries, then try home directories for password files
2. secondly – can you restart mysql? if yes, restart with –skip-grant-tables, log into mysql, change your password and restart without –skip-grant-tables
3. third option – (on linux / unix ONLY)
If you haven’t found the password anywhere and can’t afford to restart your mysql.

cd data/mysql
cp -rp user.MYD bck_user.MYD_`date +%Y%m%d`
cp -rp user.MYD /tmp/user.MYD
vi /tmp/user.MYD #(edit the hashed passwords next to root*)
cp -rp /tmp/user.MYD user.MYD
sudo kill -HUP `pidof mysqld`

Note that the latter method of recovering a root password CAN be easily used maliciously leaving no trace! The only way to avoid such an attack is to make the data directory ONLY readable and writable by the user used to start/stop mysql (don’t user *nix root user to own mysql since that opens another can of worms … it’s a whole other blog post).

Securich 0.3.0

Darren Cassar — Thu, 19 Aug 2010 21:59:19 +0000

Around these days last year I presented `securich` for the first time. It was at froscon 2009, barely knowing anybody, spending my 27th birthday in a hostel in Germany fixing some bugs before the actual presentation on a 10 inch netbook (my mac had some problems at the time but thats another story :)). I got a beating, verbally of course! Many of the people listening to the presentation were expecting something else since another presentation was supposed to be running at that time, some even started dozing off (encouraging? not really hehe) but after a few minutes people started getting interested and asking all kind of questions. “This awesome” I thought to myself, “questions are good, it means people are understanding and want to know more”, but the more they learnt the more they realised how young securich was as a tool, lacking fundamental features like reverse reconciling securich with mysql rather than the other way round, bugs cropping up (Giuseppe aka datacharmer made sure he found some on the fly :P) but oh well back then it was just four months old.

Now after a year and four months into it, Securich is still in Beta but MANY MANY more features were included, bugs fixed (others created) and it even made it through two sessions at the Oreilly MySQL Conference and Expo 2010 and two mysql university sessions.

The end points here are:
1. Share your knowledge and code with the community, we learn, you learn!
2. When you fall to the ground, climb back up and get on your feet again. Start running!
3. Securich is now at version 0.3.0 (10th official release), help yourself at google code your feedback is greatly appreciated!

Most of the new release is bug fixes but some of the features added in this version are:
1. Any user can now install securich not just mysql root
2. You can now grant privileges on the mysql db (by default still disabled as it runs in “strict” mode which needs to be changed to “lenient” manually)
3. The installation script now keeps the securich package intact for further many installations
4. Better error reporting (for debugging purposes)
5. Grants on tables using regexp are now case sensitive

MySQL – IP vs DNS

Darren Cassar — Fri, 04 Dec 2009 15:39:12 +0000

A MySQL is running happily on a machine situated in a land far far away. I grant access to a user@machine_aaaaaa (grant select on db.* to ‘user’@'machine_aaaaa’ identified by ‘password’; flush privileges;), send an email to the user saying it should run fine and happily go off my way. Mistake!

It seems this user can’t connect to the mysql gets access denied:
Access denied for user ‘user’@'machine_bbbbb’ (using password: YES)

Note that the machine the user is being seen from is totally different from the one I set up in the grant!! WHY?

run a reverse lookup on the ip of machine_aaaaa, turns out it shows machine_bbbbb. So I figure a big bad guy messed up /etc/hosts, I was right! `cat /etc/hosts` just to find an entry for machine_aaaaa blehh

Ok, solution is to remove the entry from /etc/hosts (after finding out it wasn’t even necessary and wasn’t even supposed to be there in the first place), restart nscd.

Retry
AGAIN – Access denied for user ‘user’@'machine_bbbbb’ (using password: YES)

What the ….

What’s wrong now? — yeah silly me forgot to `flush hosts` :)

Retry
YOHOO I’m in!

I’ve seen quite a few blogs about disabling name resolve in mysql with skip-name-resolve and granting privileges using IPs – something which would also have avoided the above (but still not found the root of the problem):

http://jeremy.zawodny.com/blog/archives/011421.html
http://www.mysqlperformanceblog.com/2008/05/31/dns-achilles-heel-mysql-installation/