Summary: SELinux is preventing /bin/bash "search" access on /share. Detailed Description: SELinux denied access requested by mysqld_safe. It is not expected that this access is required by mysqld_safe and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. Allowing Access: You can generate a local policy module to allow this access - see FAQ (http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Please file a bug report. Additional Information: Source Context system_u:system_r:mysqld_safe_t:s0 Target Context system_u:object_r:samba_share_t:s0 Target Objects /share [ dir ] Source mysqld_safe Source Path /bin/bash Port <Unknown> Host (removed) Source RPM Packages bash-4.0.33-1.fc12 Target RPM Packages Policy RPM selinux-policy-3.6.32-55.fc12 Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Plugin Name catchall Host Name (removed) Platform Linux (removed) 2.6.31.6-166.fc12.x86_64 #1 SMP Wed Dec 9 10:46:22 EST 2009 x86_64 x86_64 Alert Count 8 First Seen Sat 12 Dec 2009 12:08:07 PM EST Last Seen Mon 14 Dec 2009 11:31:55 AM EST Local ID 05fc5d6d-778f-4537-9861-29c50b9abb23 Line Numbers Raw Audit Messages node=(removed) type=AVC msg=audit(1260808315.214:8): avc: denied { search } for pid=1282 comm="mysqld_safe" name="/" dev=sda6 ino=2 scontext=system_u:system_r:mysqld_safe_t:s0 tcontext=system_u:object_r:samba_share_t:s0 tclass=dir node=(removed) type=SYSCALL msg=audit(1260808315.214:8): arch=c000003e syscall=4 success=no exit=-13 a0=1ce1c10 a1=7fffb1c9cdf0 a2=7fffb1c9cdf0 a3=8 items=0 ppid=1255 pid=1282 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="mysqld_safe" exe="/bin/bash" subj=system_u:system_r:mysqld_safe_t:s0 key=(null) Hash String generated from selinux-policy-3.6.32-55.fc12,catchall,mysqld_safe,mysqld_safe_t,samba_share_t,dir,search audit2allow suggests: #============= mysqld_safe_t ============== allow mysqld_safe_t samba_share_t:dir search;
This happens during init. It is a basic install of MySQL, no special configuration. It looks like mysqld_safe has it's own clumsy implementation of 'which'--called my_which()--that wants to search the entire filesystem for 'logger'. Wouldn't it be more appropriate (an efficient) to limit the search dirs to /bin, /sbin, /usr, and maybe a few other binary dirs used on other *NIX systems that have a 'logger' binary? An SELinux policy change seems insecure for this behaviour.
I agree, the mysql_save code is causing bizarre avc's all over the place, could this code be cleaned up. I think it is safe to expect logger to be in the default path.
What mysql version is this?
I have the default F12 repo version of mysql on the system: mysql-5.1.40-1.fc12.x86_64 mysql-embedded-5.1.40-1.fc12.x86_64 mysql-libs-5.1.40-1.fc12.x86_64 mysql-server-5.1.40-1.fc12.x86_64
Hmm, I do not see any AVC's on F-11 using the same SRPM. Has the policy for mysql been changed in F-12?
Looking at the code you identify as the culprit, I see that (1) it only looks at the directories in $PATH, and (2) it's not invoked at all unless you've requested syslog logging. So I could see how you'd get this result if you changed the mysql config to select syslog logging and changed the global PATH setting to include "/share", but that hardly qualifies as "no special configuration" in my book. I'm not particularly convinced that I should lobotomize the code to not check that logger is present. Yes, it's probably a waste of time on a Fedora system, but I'm not interested in carrying a patch that upstream would never take back, and I don't think that searching $PATH is an unreasonable thing to do. Wouldn't that happen implicitly during exec() anyway? If you're running daemons with a PATH that includes /share, I think you oughta treat that as a secured directory and give it an appropriate selinux label.
Tom I don't believe that is what is happening. I think the user has a mount point /share, which he is labeled correctly. For some reason your script is searching the directories of all mountpoints in /etc/mtab. Perhaps it is running df and this is causing the access. The policy on the mysqld_safe was added in F12.
Tom, I did not customise the configuration for MySQL in any way. All I did was install it from the DVD and set mysqld_safe to run at init along with apache. Changed root password, and added a DB. I don't remember if there was an update, but if so it was applied. mysqld_safe should not even know about any special mount points I have made. They are not added to any users $PATH. No binary packages are installed to my /share mount. And, there are no symlinks in any $PATH dir that point to anything on my /share mount. I have made no SELinux policies that should affect mysql. I.e., the only SELinux-related change I have made is to the context of /share as a Samba dir. But, why would that cause mysqld_safe to produce avc's? Maybe the my_which() routine that I suspected is not the real culprit, and Dan's more on track with what is actually happening here. Here is my (i.e., the "default") my.cnf if it helps: ========================================= [mysqld] datadir=/var/lib/mysql socket=/var/lib/mysql/mysql.sock user=mysql # Default to using old password format for compatibility with mysql 3.x # clients (those using the mysqlclient10 compatibility package). old_passwords=1 # To allow mysqld to connect to a MySQL Cluster management daemon, uncomment # these lines and adjust the connectstring as needed. #ndbcluster #ndb-connectstring="nodeid=4;host=localhost:1186" [mysqld_safe] log-error=/var/log/mysqld.log pid-file=/var/run/mysqld/mysqld.pid [ndbd] # If you are running a MySQL Cluster storage daemon (ndbd) on this machine, # adjust its connection to the management daemon here. # Note: ndbd init script requires this to include nodeid! connect-string="nodeid=2;host=localhost:1186" [ndb_mgm] # connection string for MySQL Cluster management tool connect-string="host=localhost:1186" =========================================
Well, color me confused. I am entirely unable to reproduce any AVC messages from initializing/starting/stopping mysqld on an up-to-date F-12 system with default /etc/my.cnf contents. I made a point of adding some nondefault mount points in the system, but still nothing (unless selinux treats your samba mount differently from my autofs NFS mount?). I can get some AVC failures if I change the mysql config to enable syslog logging: the policy doesn't seem to want to let /usr/bin/logger be called by mysqld_safe, which is something Dan needs to fix now that syslog support exists in mysqld_safe. But that apparently is not the issue you're seeing. Is there any simple way to determine which part of the mysqld_safe script is actually triggering the error? I think we've eliminated my_which.
Greg, does this happen evertime you start mysql? If yes. Can you add a -x to mysql_safe and grab the output.
Dan: yes, it happens every time mysqld_safe runs at init. But, there appear to be caveats... see my note to Tom, below. Here is what you requested: [root@x86_64f12 /]# /usr/bin/mysqld_safe -x 091218 12:21:10 mysqld_safe Logging to '/var/log/mysqld.log'. 091218 12:21:10 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql 091218 12:21:10 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended [root@x86_64f12 /]# My fstab and mtab entries for the mount point are: fstab: UUID=ae99e627-9970-46d2-b89d-dbed92d87389 /share ext3 defaults 1 2 mtab: /dev/sda6 /share ext3 rw 0 0 Tom: I think I'm getting closer to the source of the confusion... The avc's are not happening when I run mysqld_safe directly, with or without args (as root). It seems only to produce avc's when launched from the init script (i.e., when "S64mysqld start" is called). ./S64mysqld start calls mysqld_safe with the following args: /usr/bin/mysqld_safe --datadir="/var/lib/mysql" \ --socket="/var/lib/mysql/mysql.sock" \ --pid-file="/var/run/mysqld/mysqld.pid" \ --user=mysql >/dev/null 2>&1 & I don't know why, but it seems to happen only when S64mysqld calls mysqld_safe from this line in start(): /usr/bin/mysqld_safe --datadir="$datadir" --socket="$socketfile" \ --pid-file="$mypidfile" \ --user=mysql >/dev/null 2>&1 & But, for some reason when I run (as root) the same resultant command with the args that S64mysqld determines (minus the stdout silencing), I do not get the avc's. [root@x86_64f12 /]# /usr/bin/mysqld_safe --datadir="/var/lib/mysql" \ > --socket="/var/lib/mysql/mysql.sock" \ > --pid-file="/var/run/mysqld/mysqld.pid" \ > --user=mysql & [1] 5582 [root@x86_64f12 /]# 091218 13:05:33 mysqld_safe Logging to '/var/log/mysqld.log'. 091218 13:05:33 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql [root@x86_64f12 /]# Could the problem be oustide the code, and maybe have something to do more specifically with init calling mysqld_safe, instead? Still, I'm thoroughly confused by the nature of the avc. I have no idea why it should complain about a mounted partition that mysqld_safe should know nothing about.
The lack of AVCs during a manual invocation is unsurprising: I think that selinux only tries to confine the program when it's run as a daemon, not when it's run manually. (Dan will correct me if that's too much of an oversimplification.) The best approach might be to temporarily modify the init script itself: I think that adding -x to the initial "#!/bin/bash" line would accomplish the goal.
Yes, running we do not transition unless it is run from the init script. Init script works something like unconfined_t -> initrc_exec_t -> initrc_t -> mysql_safe_exec_t -> mysql_safe_t WHile direct does unconfined_t -> mysql_safe_t -> unconfined_t
Tom... I'm not sure why I never knew of the -x debug for bash. I've always done the debugging the hard way with 'echo'. Go figure. I did find that mysqld_safe is testing for dirs on /share, but I have no idea why. The avc's occur with and without the bash debug flag. In the debug output of mysqld_safe, lines 24 & 25 are addressing "./share/mysql..." based on the variable "relpkgdata" in line 20 of the output (line 211 of mysqld_safe): + relpkgdata=./share/mysql ... + test -f ./share/mysql/english/errmsg.sys -a -x /etc/rc5.d/bin/mysqld + test -f ./share/mysql/english/errmsg.sys -a -x /etc/rc5.d/libexec/mysqld 'sed' in this line (#211) in mysqld_safe is not returning what it's probably supposed to: relpkgdata=`echo '/usr/share/mysql' | sed -e 's,^/usr,,' -e 's,^/,,' -e 's,^,./,'` That just returns "./share/mysql". I guess on 99.9999% of systems this situation just goes unnoticed. Maybe I was just the random idiot to create a partition named "/share" that encountered it. Am I seeing this correctly? Or is it just behaving this way on my installation? I would attach the the debug output for both S64mysqld and mysqld_safe, but there doesn't seem to be an 'attach' thingie.
Created attachment 379370 [details] mysqld_safe bash debug output Lines 20, 24 & 25 show the ./share var assignment and test that seem to be producing the avc's
Ok, I found the attach thingie.
Hm, still no smoking gun here. The bit you are looking at seems to be probing /etc/rc5.d/share/, since it's looking for ./share while pwd is /etc/rc5.d. So it's not apparent to me that that would have any relationship to a /share mount point. I still don't see what's causing the AVC. Dan, do you see it?
Tom, I decided to test the "./share/mysql" suspicion in those "test -f" lines: I renamed and re-mounted my /share partition as "/sharedir" and the avc's stopped. I set the mount point back to "/share" and the avc's started again. So, I think it's the syntax of those test -f lines that is not doing quite what it's supposed to do. Also, is there ever an /etc/rc[X].d/share dir? I'm not familiar enough with other *NIXes to know if that would be a normality on another distro. Is there a distro installation where either of those two test lines will ever return true? At least on my installation, it seems the -f test should be for /usr/share/mysql/english/errmsg.sys, which is exactly what the sed call is changing to "./share". And at least on Fedora and RHEL (and SuSE, if I can remember correctly) I've never seen any dirs beneath /etc/rc[X].d. Are there cases where these tests are necessary?
Oh... and it seems the reason for SELinux complaining is that I had changed the default type of the "/share" Samba share to "samba_share_t". SELinux is now (not previously) recommending I change the default type to "etc_runtime_t". I can't do that, because my Samba share won't be happy.
What I first thought when looking at those lines is that if the script were being run with cwd = / then the probes of "./share" would reference "/share" and all would be explained. However, it's perfectly clear from the pwd result assigned to MY_PWD that the current directory is /etc/rc5.d. Dan, is it possible that selinux thinks the current directory is / when it really isn't? Greg: the reason for all those tests is that this is a generic script that's intended to work in a variety of different filesystem layouts. It's trying to figure out which layout it's being run in. We could in fact lobotomize most of those tests for Fedora's purposes; but I would very much prefer not to, because it'd be a patch that I'd have to carry forever --- upstream would certainly never take it back, because the entire point of that code is to run in environments other than Fedora. Also, although your test proves that the specific name /share is somehow implicated in this, it's not clear to me that we have yet proven which part of the script is trying to touch /share. The theory that it's this particular part has a large hole in it, namely the MY_PWD result.
Hmm, I can get the AVC if I create /share and mark it with a context that selinux will prevent mysql from touching. What's even more interesting is that my trace from running mysqld_safe with -x looks like ... + relpkgdata=./share/mysql ++ pwd + MY_PWD=/ + test -n '' -a -d '' + test -f ./share/mysql/english/errmsg.sys -a -x //bin/mysqld + test -f ./share/mysql/english/errmsg.sys -a -x //libexec/mysqld + MY_BASEDIR_VERSION=/usr + ledir=/usr/libexec ... So for me, the script is run in the root directory (not surprising). But Greg's trace clearly shows a different current directory. How can that be? I'm testing this on F-11, is it possible F-12 changed the convention? If it did, why is Greg getting a failure?
Looking at the info again, it seems like the most probable explanation is 'pwd' delivering a wrong result on Greg's machine; but still confused why/how.
mysqld_safe is testing all subdirs of the current working directory? So for any label in / mysqld_safe would either need to be allowed or dontaudited from searching the directory, correct?
No, it's only looking at ./share. I can probably make it not do that, but what still requires explanation before proceeding to a fix is why Greg's trace makes it look like /etc/rc.5.d/share is being probed.
Tom, apparently the confusion about the "/etc/rc.5.d/share" search is my fault. I was running the S64mysqld script directly, as root ("./S64mysqld"), while root's pwd was /etc/rc5.d. I removed the redirect from the call in S64mysqld to mysqld_safe and re-ran the script with "service mysqld start". In this case, MY_PWD in mysqld_safe returns '/' just before those two tests in the elifs on lines 230 & 235 of mysqld_safe: 230: elif test -f "$relpkgdata"/english/errmsg.sys -a -x "$MY_PWD/bin/mysqld" 235: elif test -f "$relpkgdata"/english/errmsg.sys -a -x "$MY_PWD/libexec/mysqld" So, this is actually testing: + test -f ./share/mysql/english/errmsg.sys -a -x //bin/mysqld + test -f ./share/mysql/english/errmsg.sys -a -x //libexec/mysqld I'm not sure why pwd is '/', and I'm also not sure who 'service ... start/stop' runs as, but I was in '/etc/rc5.d' when I ran 'service ... start' so root's pwd was not '/'. Also--somewhat unrelated, here--it looks as though MY_BASEDIR_VERSION is not getting assigned any args in the 'for arg do... case...' loop starting at line 157. It doesn't get assigned to '/usr' (arbitrarily) until after the tests in lines 230 & 235. But, that might be intentional to make the first conditional fail. But, it looks like MY_BASEDIR_VERSION is always going to be set to '/usr'. And, that whole conditional from line 209 to 215 still confuses me. I can't stop thinking the original intention was for the logic to do something a bit different. In any case, it doesn't seem to matter how I run the script--from init, as root, as a service--it only produces the avc's when the mounted partition is called '/share'.
Created attachment 379701 [details] inline output of S64mysqld & mysqld_safe run as service This output stream shows the pwd uncorrupted by being run directly as root. This was produced running 'service mysqld start', instead of how I ran it before ("./S64mysqld" as root, while in /etc/rc5.d). Lines 107-110 echo the values of MY_PWD and MY_BASEDIR_VERSION which are still not getting set as probably expected. This also includes mysqld_safe output wrapped by S64mysqld script output after the bash redirect was removed from the call to mysqld_safe.
Tom, Somehow I completely missed comments 20 & 21. Yes, you are correct in that I was running the script in /etc/rc5.d. I discovered my mistake yesterday morning. And starting mysqld via 'service...start' yields the same result you get in your output. My thought is that somehow "./share" might not be correct, or at least wrong for Fedora/RHEL. Are there distros that have /share as a mount point hanging off root? That particular bit of code looks to me like that sed should have replaced /usr with something other than ./ to prefix the dir more specifically for other distros where the mysqld binary and error messages would not be /usr/share/mysql. Since I don't know the different locations where it should wind up, I can only guess based on my experience with Fedora/RHEL and SuSE. I completely agree that labotomising the code specifically for Fedora is a bad idea. Maybe those relpkgdata and MY_PWD assignments could use a little more logic? If I knew all the conditions, I could help supply some code to replace with, but I'm not sure what needs to be tested for.
It looks like the easiest way to suppress this message is to add "--basedir=/usr" to the arguments passed to mysqld_safe, around line 75 of /etc/init.d/mysqld. This prevents mysqld_safe from probing into other parts of the filesystem tree.
mysql-5.1.42-2.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/mysql-5.1.42-2.fc12
mysql-5.1.42-2.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/mysql-5.1.42-2.fc11
mysql-5.1.42-2.fc12 has been pushed to the Fedora 12 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update mysql'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F12/FEDORA-2010-0128
mysql-5.1.42-2.fc11 has been pushed to the Fedora 11 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update mysql'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2010-0130
mysql-5.1.42-2.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.
mysql-5.1.42-2.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.