Bug 547485 - SELinux is preventing /bin/bash "search" access on /share.
Summary: SELinux is preventing /bin/bash "search" access on /share.
Alias: None
Product: Fedora
Classification: Fedora
Component: mysql
Version: 12
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Tom Lane
QA Contact: Fedora Extras Quality Assurance
Whiteboard: setroubleshoot_trace_hash:f0fb05ac2c1...
Depends On:
TreeView+ depends on / blocked
Reported: 2009-12-14 19:09 UTC by Greg Stewart
Modified: 2013-07-03 03:25 UTC (History)
6 users (show)

Fixed In Version: 5.1.42-2.fc12
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2010-01-19 19:35:54 UTC
Type: ---

Attachments (Terms of Use)
mysqld_safe bash debug output (8.26 KB, text/plain)
2009-12-19 16:52 UTC, Greg Stewart
no flags Details
inline output of S64mysqld & mysqld_safe run as service (12.86 KB, text/plain)
2009-12-21 20:07 UTC, Greg Stewart
no flags Details

Description Greg Stewart 2009-12-14 19:09:27 UTC

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

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) #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;

Comment 1 Greg Stewart 2009-12-14 19:25:21 UTC
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.

Comment 2 Daniel Walsh 2009-12-15 13:52:40 UTC
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.

Comment 3 Tom Lane 2009-12-15 14:38:21 UTC
What mysql version is this?

Comment 4 Greg Stewart 2009-12-16 16:23:08 UTC
I have the default F12 repo version of mysql on the system:


Comment 5 Tom Lane 2009-12-17 01:49:59 UTC
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?

Comment 6 Tom Lane 2009-12-17 02:22:08 UTC
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.

Comment 7 Daniel Walsh 2009-12-17 14:00:54 UTC
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.

Comment 8 Greg Stewart 2009-12-17 15:56:27 UTC
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:

# Default to using old password format for compatibility with mysql 3.x
# clients (those using the mysqlclient10 compatibility package).

# To allow mysqld to connect to a MySQL Cluster management daemon, uncomment
# these lines and adjust the connectstring as needed.


# 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!

# connection string for MySQL Cluster management tool

Comment 9 Tom Lane 2009-12-17 17:29:30 UTC
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.

Comment 10 Daniel Walsh 2009-12-17 19:10:40 UTC
Greg, does this happen evertime you start mysql?

If yes.

Can you add a -x to mysql_safe and grab the output.

Comment 11 Greg Stewart 2009-12-18 18:11:59 UTC
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:

UUID=ae99e627-9970-46d2-b89d-dbed92d87389 /share  ext3  defaults  1 2

/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.

Comment 12 Tom Lane 2009-12-18 18:35:28 UTC
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.

Comment 13 Daniel Walsh 2009-12-18 20:52:49 UTC
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

Comment 14 Greg Stewart 2009-12-19 16:40:34 UTC
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.

Comment 15 Greg Stewart 2009-12-19 16:52:40 UTC
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

Comment 16 Greg Stewart 2009-12-19 16:53:48 UTC
Ok, I found the attach thingie.

Comment 17 Tom Lane 2009-12-19 19:46:49 UTC
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?

Comment 18 Greg Stewart 2009-12-20 18:02:32 UTC
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?

Comment 19 Greg Stewart 2009-12-20 18:39:20 UTC
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.

Comment 20 Tom Lane 2009-12-20 19:23:30 UTC
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.

Comment 21 Tom Lane 2009-12-20 20:27:46 UTC
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
+ 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?

Comment 22 Tom Lane 2009-12-20 23:32:52 UTC
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.

Comment 23 Daniel Walsh 2009-12-21 16:26:47 UTC
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?

Comment 24 Tom Lane 2009-12-21 17:02:50 UTC
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.

Comment 25 Greg Stewart 2009-12-21 20:00:16 UTC
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'.

Comment 26 Greg Stewart 2009-12-21 20:07:46 UTC
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.

Comment 27 Greg Stewart 2009-12-22 16:20:39 UTC
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.

Comment 28 Tom Lane 2010-01-02 00:18:12 UTC
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.

Comment 29 Fedora Update System 2010-01-03 00:22:26 UTC
mysql-5.1.42-2.fc12 has been submitted as an update for Fedora 12.

Comment 30 Fedora Update System 2010-01-03 00:22:32 UTC
mysql-5.1.42-2.fc11 has been submitted as an update for Fedora 11.

Comment 31 Fedora Update System 2010-01-03 21:03:40 UTC
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

Comment 32 Fedora Update System 2010-01-03 21:04:34 UTC
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

Comment 33 Fedora Update System 2010-01-19 19:35:47 UTC
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.

Comment 34 Fedora Update System 2010-01-19 19:42:51 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.