Bugzilla – Bug 3847
my.cnf permissions not explicitly set; MySQL ignores the file when world writable
Last modified: 2011-03-16 04:34:08 UTC
SlimServer 6.5b 2006-07-30 Solaris SPARC 9 12/03 (Update 5) When the SlimServer first creates its db cache directory, the my.cnf file it places in it has inappropriate permissions. I haven't checked to see if the permissions are coming from the process umask or from SlimServer itself. Either way, the file has permissions which MySQL doesn't like and therefore ignores the my.cnf file. Net, net, things don't work until the permissions are manually fixed. Thus, it might be a Good Thing were SlimServer to manually set the permissions for the file after creating it from my.tt (or whatever). Here's the output from SlimServer when it created my.cnf *********************** 2006-07-31 10:47:22.8370 MySQLHelper: createConfig() Creating config from file: [/usr/local/src/SlimServer_v2006-07-30/MySQL/my.tt] -> [/export/home/slimserver-beta/Cache/my.cnf]. ************************ 2006-07-31 10:47:23.1507 MySQLHelper: init() Creating system tables.. 2006-07-31 10:47:23.1530 MySQLHelper: startServer() About to start MySQL with command: [/usr/sbin/mysqld --defaults-file=/export/home/slimserver-beta/Cache/my.cnf --pid-file=/export/home/slimserver-beta/Cache/slimserver-mysql.pid --log-error=/export/home/slimserver-beta/slimserver.log] ************************ Warning: World-writable config file '/export/home/slimserver-beta/Cache/my.cnf' is ignored ************************ And here's the permissions of the files in the cache directory which it created. Note that my.cnf is 0666 but should be something more like 0644 or 0600. drwxr-xr-x 3 slimbeta staff 512 Jul 31 10:47 . drwxr-xr-x 3 slimbeta staff 512 Jul 31 10:47 .. drwxrwxrwx 2 slimbeta other 512 Jul 31 10:47 MySQL -rw-rw-rw- 1 slimbeta other 944 Jul 31 10:47 my.cnf The permissions on the MySQL directory are also too permissive but they at least don't cause MySQL to ignore the directory
It's heartbreaking, but I don't actually have a Solaris system to test on. I don't see this issue with my linux installs, though. Is there something specific to Solaris permissions that might cause this to be happening?
I doubt that Solaris the OS is doing something different here. Again, this may simply be a "umask" issue. Or, it could be a difference between your MySQL and mine with mine being more paranoid about permissions. FWIW, I'm running # mysqld --version mysqld Ver 5.0.22-standard for sun-solaris2.9 on sparc (MySQL Community Edition - Standard (GPL)) If on your Linux box, the permissions allow world WRITE, then my MySQL is simply more paranoid than yours. If, however, on your Linux box the permissions do not allow WORLD write, then I would suspect "umask" or inherited permissions as being the culprit. This isn't, after all, Windows with its myriad ACLs, ACIs, and other half implemented, honored in the breach, bizarre-o permissions systems. Regardless, this looks to me like an oversite in MySQLHelper:: . Specifically, if mysqld is going to be picky (and rightfully so) about the permissions on the config file it is pointed at (my.conf in this case), then MySQLHelper's code to produce an initial config file should be mindful of this and set the permissions to 0xy0 or 0x00 on the config file it creates. Seems generally more robust IMO and certainly more secure (e.g., should there be a bug in a future version of mysqld which fails to check the permissions of the config file). Anyhow, for purposes of academic interest and root cause analysis, I'm happy to look further into if this is a umask issue or similar. However, you may nonetheless want to add chmod 0660, $output; # Don't trust my Perl code: I code Perl about once a year to MySQLHelper::createConfig().
I've checked in change 8864 which does an explict chmod of the config file.
I assume Dan meant to mark this fixed when he made his comment about it being fixed in change 8864, so I will do so now. If anyone continues seeing this behavior, please reopen the bug.
Actually, I reverted the change, as it started causing issues for other users.
hmm well maybe I ought to install an x86 Solaris as Dan suggested and have a closer look
For my own notes: the problem Dan reports other users experiencing appears to be here: http://forums.slimdevices.com/showthread.php?p=127475#post127475
I wonder if chmod 0664 would work better? Sounds like some folks might need world READ access on the file. The original mysqld error was a complaint about the file being world WRITE. It was my knee-jerk reaction to suggest no world access (0660) as that is my general reaction to config files since occassionally they sometimes have the habit of having passwords stored in 'em.
Subject: Re: my.cnf permissions not explicitly set; MySQL ignores the file when world writable Tried that as well, it still didn't work (why, I don't know). Don't really have time to dig into it that much.
And, for the record, running as "root" on my Solaris 9 U5 SPARC system, those unwanted permissions were indeed a result of permission defaults. That is, you're getting the default permission mask on that file as per the umask setting for the user. Here's an example below, where running as root I show the "umask" in effect -- my root's default setting -- and the result it has on a newly created file. I then change the umask and get a different set of permissions on subsequently created files. # umask 000 # mkdir /Cache # ls -ald /Cache drwxrwxrwx 2 root other 512 Aug 8 14:23 /Cache # cd /Cache # cat > a.cnf ddd # ls -al total 8 drwxrwxrwx 2 root other 512 Aug 8 14:23 . drwxr-xr-x 41 root root 1536 Aug 8 14:23 .. -rw-rw-rw- 1 root other 4 Aug 8 14:23 a.cnf # cd / # rm -rf /Cache # umask a=rx,ug+w # umask 002 # mkdir /Cache # ls -ald /Cache drwxrwxr-x 2 root other 512 Aug 8 14:28 /Cache # cd /Cache # cat > a.cnf ddd # ls -al a.cnf -rw-rw-r-- 1 root other 4 Aug 8 14:28 a.cnf
Chris, when you tried to reproduce this on Linux, did you launch slimserver.pl whilst running as root with a "umask" of 0? Might try giving that a spin. I mention that as that was my usage scenario. FWIW, I did tell slimserver.pl to run with different uid via the --user switch. However, given that those initial configuration files were created owned by root, I assume that the process had not yet changed its effective uid away from root. That, in turn, makes me further wonder if (1) mysqld was launched as root, and (2) if when launched as root mysqld is extra paranoid about my.cnf permissions. (The paranoia about those permissions dating back to MySQL 3.23.56 -- that being, if I recall correctly, the fix to the root compromise associated with mysqld running as root and the my.cnf file having world write acces. That is, I believe, the compromise which allowed hackers to scribble on the apache.org web pages once upon a time.)
Dan Sully's attempted fix didn't work out. We have a workaround (Solaris users, change your permissions by hand). I'll have a more detailed look at this for 7.0.
Is this issue still open or can this bug be closed?
I'm not running slimserver on Solaris anymore so I'm no longer in a position to comment on whether or not this issue is resolved.
No longer an issue for Dan. Please reopen if somebody still has this issue.
This bug is being closed since it was resolved for a version which is now released! Please download the new version of SqueezeCenter (formerly SlimServer) at http://www.slimdevices.com/su_downloads.html If you are still seeing this bug, please re-open it and we will consider it for a future release.