down and dirty with mysql

by Karanbir Singh Email

Do not try this at home.

Just use 'sed' to change data stored inside a running mysql db. And it worked too. Saw the change data come through within a few seconds. Wonder what the internal mysql process did when it realised that data on the filesystem had changed from what it had in cache. Although there is a good chance that no such test exists inside mysql to start with.

Scary thing is, this whole process worked. Which also means, in case you havent caught on yet, is that its possible to change users passwords and change data stored on file off the command line. Not sure why this surprises me, considering myisam tables are just flat files on disk. Still. Something to think about.

Selinux would help here.

- KB

7 comments

Comment from: BenCollver [Visitor]
Would file system permissions help? For example, the mysql data could be writable only to a nologin mysql user.
29/Mar/2009 @ 20:31
Comment from: Karanbir Singh [Member] Email · http://www.karan.org/
Ben, yea - you can lock the mysql db store using ACL's. ofcourse, it would help even more if no non-trusted users had access to the local filesystem completely. It just surprised me that it was so trivial switching passwords.

My sed job changed data for about a million rows, and had nothing to do with password mash'ing.
29/Mar/2009 @ 20:39
Comment from: Brian [Visitor]
MyISAM tables have no cache for data, only for indexes. So, not surprising that your changes came through. However, if you changed the size of a field instead of just replacing characters, it seems like you could rapidly corrupt the table. Also, if you were swapping the MDB one with a new, altered version through sed (or perl, etc), you might experience problems related to open file handles in the db and need to flush tables before you would see the updates.

The privilege system is cached, on the other hand. If you changed the privilege tables manually or through mysql (rather than using grant statements), you wouldn't see any changes until someone executed Flush Privileges or restarted MySQL.


Typically only root or mysql can read or update the MySQL datastore, and if either of these users is compromised, you're toast anyway.
30/Mar/2009 @ 02:27
Comment from: Morten [Visitor]
mysql isn't an ACID database, there are no guarantees of anything related to data security this way or the other. Slowly, features for this is creeping into mysql, but it is still a toy database compared to DB2, Informix or other RDBMS.
30/Mar/2009 @ 02:50
Comment from: Richard Edward Horner [Visitor] · http://richhorner.com
"Wonder what the internal mysql process did when it realised that data on the filesystem had changed from what it had in cache."

I was about to say that it probably didn't but you beat me to it.

"Although there is a good chance that no such test exists inside mysql to start with."

I am not surprised in the least. MySQL is such a piece of junk.

People, if you need a FOSS RDBMS, please use PostgreSQL. It makes everyone's life better. Thanks.
30/Mar/2009 @ 13:14
Comment from: Karanbir Singh [Member] Email · http://www.karan.org/
Richard,

that sounds a bit extreme. While pgsql could potentially be a better all roun db, I think mysql definitely has its place.
30/Mar/2009 @ 15:34
Comment from: abbe [Visitor] · http://wahjava.wordpress.com/
Okay, I'll try that at office ;)
31/Mar/2009 @ 11:52

Leave a comment


Your email address will not be revealed on this site.

Your URL will be displayed.
(Line breaks become <br />)
(Name, email & website)
(Allow users to contact you through a message form (your email will not be revealed.)