Hide Forgot
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 Description of problem: [mgt@supernova docs]$ uname -a Linux supernova 2.6.9-1.681_FC3 #1 Thu Nov 18 15:11:31 EST 2004 i586 i586 i386 GNU/Linux When starting mysql-server for the first time /etc/init.d/mysqld start It fails and produces the error /usr/libexec/mysqld: Table 'mysql.host' doesn't exist Upon further searching it is clear that no databases are in /var/lib/mysql/mysql and no amount of running mysql_install_db will create them. UNLESS you first do a setenforce 0 /etc/init.d/mysqld start setenforce 1 Turning off selinux allowed the databases to be made. Sadly I'm not very good with the policy's so I don;t have the real solution at this time. Version-Release number of selected component (if applicable): selinux-policy-targeted-1.17.30-2.34 mysql-server-3.23.58-13 How reproducible: Always Steps to Reproduce: 1.Install Fedora Core 3 with selinux targetted policy and mysql-server 2.start mysql-server 3. Actual Results: /usr/libexec/mysqld: Table 'mysql.host' doesn't exist Expected Results: Databases made in /var/lib/mysql/mysql Additional info:
mysql-4.1.7-4 looks like it fixes this problem. I am trying to get it updated for FC3.
Created attachment 107631 [details] Patch to fix install_db and SELinux conflict. I believe this patch will fix the problem in mysql-3.23.58
Will stick the patch into the next FC3 rev. Just out of curiosity, though, what restriction are we dealing with here? I see that the 4.1 mysql_install_db script still pipes data into an eval call of mysqld, so I am confused about what is going on. Why do both that version and your patch avoid the security violation?
The initial syntax mysql ... << EOF Blah Blah Blah EOF When an admin runs the mysql_install_db the script will run in the context of the admin, and it creates a temporary file in /tmp. In targeted policy that file is created with tmp_t policy. (sysadm_tmp_t in strict). When the script starts mysqld it runs in the mysql_t domain and the program tries to read the temporary file. It is denied so the database does not get created. So If I wanted to allow that syntax to work, I would have to allow mysql_t to read all files in /tmp which is not required for normal running of the database and could be used as a breach of security. By changing it to the echo or cat syntax, the admin program reads the temporary file and pipes it to mysql which is allowed. Dan
Wait a minute. You're saying that SELinux considers it acceptable to break the <<EOF syntax, globally? I don't think this is a mysql bug, at all. You cannot just decree that a standard feature of shell scripting isn't going to work anymore. Perhaps an appropriate fix would involve changing bash so that <<EOF doesn't write a temp file, or does it in some more secure way than using /tmp.
That is not what I am saying. The problem is that you have two different programs running under different context passing information in such a way that the less trusted application has to read files files created by the more trusted domain. So the << EOF syntax will work in almost all cases, the problem is using it with a program that is transitioning. Dan
But the less trusted program is being passed a file descriptor already opened by the more trusted one. Surely the protection check should apply to the act of opening the file, not the act of reading from an FD you are given. I thought the patch you gave originally was ugly, and was considering changing it to cat <<EOF ... EOF | mysqld but am now completely confused as to whether that will work or not.
cat <<EOF ... EOF | mysqld Will work fine. In my patch it is, in the original it is not. cat << EOF ... EOF | mysqld hands mysqld an open file descriptor mysqld << EOF ... EOF Hands mysqld a temporary file to be opened. The application is actually opening the file, the shell is not passing an open file descriptor.
Hmm ... in that case I'm back to the thought that it's a bash bug. A reasonable person would expect that <<EOF would pass the contents of the here-document as already-opened stdin, not as a file that might have security issues. If it sounds like I'm trying to get out of applying a patch to mysql, it's not that; it's that I think this is the tip of an iceberg, and we'd better fix the root cause rather than the first symptom we come across. There are going to be LOTS more scripts just like this one.
Adding bash package maintainer for possible comment.
Here documents may need to have expansions performed. You cannot assume that the implementation will not create temporary files, or that if it does not it never will in the future. In fact bash is passing an open file descriptor to the temporary file. The application does not open it; bash does.
That's what I would have expected bash to do. So it seems that dwalsh's explanation of the problem is off base, and I'm still wondering exactly what it is we are working around here...
Not exactly, in the case where the files were created in /tmp, bash is handing the application a file descriptor connected to a tmp_t or sysadm_tmp_t file, mysqld_t does not have the rights to read the file since it was created by a more trusted domain. In the cat << EOF ... EOF case the Reading of the file is being done by the cat program running under the more trusted domain and mysql is just reading from a pipe. Dan
Yes, sounds right. Piping the cat output (which takes input from a here document) into mysqld should be fine as far as selinux is concerned, since mysqld is not reading directly from the temporary file.
*** Bug 141434 has been marked as a duplicate of this bug. ***
In preparation for fixing this, I tried to reproduce the failure on my own machine, and could not. sudo /sbin/service mysqld stop sudo /usr/sbin/setenforce 1 sudo rm -rf /var/lib/mysql/* sudo /sbin/service mysqld start Initializing MySQL database: [ OK ] Starting MySQL: [ OK ] This is with selinux-policy-targeted-1.19.11-3 and mysql-3.23.58-13. What am I missing?
Does it have a database when you are finished?
Yeah, all the files seem to be created. I'm thinking that SELinux may be disabled somehow, but I don't see how --- the config file looks right (though I have it defaulting to permissive mode). Is there any easy way to trigger a violation to check, when using the targeted policy?
You got to the test in Enforcing mode. setenforce 1
I did.
Ok. for the mere mortals around here that just has the problem with mysqld not starting. This works on my vanilla FC3 default install system with all updates installed as of 041216: 1. Remove the database with # rm -rf /var/lib/mysql 2. Temporarily disable selinux with # /usr/sbin/setenforce 0 3. Initialize and start mysql with # /etc/init.d/mysqld start 4. Enable selinux again with # /usr/sbin/setenforce 1 Good luck with the package update!
In the startup script for mysql this is called : # If you've removed anonymous users, this line must be changed to # use a user that is allowed to ping mysqld. ping="/usr/bin/mysqladmin -uUNKNOWN_MYSQL_USER ping" # Spin for a maximum of ten seconds waiting for the server to come up UNKNOWN_MYSQL_USER is not set and then the script will fail. (It will not fail with "/usr/sbin/setenforce 0"). But just changing UNKNOWN_MYSQL_USE to a user that is allowed to ping will also work! Kees.
Because Tom Lane (tgl@redhat.com) seems to be a bit stuck on this (see https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=141062#c16 thru https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=141062#c20) I did a bit of testing. The system I did this on is a fairly clean FC3 (new install; kept only /home from FC2 time; yum update to most recent updates; a few packages from Dag's repository but nothing significant, I think) Relevant specific packages are: mysql-server-3.23.58-13 selinux-policy-targeted-1.17.30-2.62 With "Enforcing" I indeed get the problem that the database doesn't get properly created due to the security problem with the temporary file. After a cleanup and with "Permissive" I still get some audit messages but the database gets properly created. Before switching back to "Enforcing" I had to do a restorcon /var/log/mysqld.log. After that things are back to normal. Next I cleaned-up once more and installed: mysql-4.1.7-8.i386.rpm mysql-server-4.1.7-8.i386.rpm No problem! This seem all consistent with almost everything but: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=141062#c16 The system Tom Lane (tgl@redhat.com) is using has at least a different selinux-policy-targeted --> 1.19.11-3 from the FC4 development tree. There is a fix to mysql.te in there. Could that be the reason that Tom can't reproduce the problem? Or is his system more different from the FC3 most of us are using?
After installing selinux-policy-targeted-1.19.15-14 from the development tree I cleaned-up once more and installed mysql-server-3.23.58-13. Same behaviour. The version of the security policy doesn't seem to matter.
No this is a problem with the mysql-server-3.23.58-13 pachage. Comment #8 describes the problem. It has been fixed in the mysql-server-4 versions and beyond. The work around to get the database setup is just setenforce 0 service mysql start setenforce 1 After the database is established it should just work. Dan
I was able to reproduce the problem on my own machine this morning; I'm still not sure why it didn't fail before, but at least I can see that Dan's proposed patch does indeed do something. Patch pushed out for FC3 in mysql-3.23.58-14.
No love here, After installing the lastest mysql (3.23.58-14) I still have the problem. I can run mysql with setenforce set to 0, however, as soon as I /usr/sbin/setenforce 1, I can no longer start mysqld. Here is the error I get, it looks like mysqld is being denied write access to /var/lib (I'm no selinux expert but that seems like what this is saying... Jan 6 14:43:19 test kernel: audit(1105051399.633:0): avc: denied { write } for pid=3534 exe=/usr/libexec/mysqld name=mysql dev=dm-3 ino=6864943 scontext=root:system_r:mysqld_t tcontext=root:object_r:var_lib_t tclass=dir
You need to relabel the package rpm -q -l mysql-server mysql | restorecon -R -v -f - Dan
Dan, shouldn't the RPM upgrade have done that automatically?
RPM upgrade of what. We don't do a relabel on policy upgrade, because it would be to invasive and could take a very long time. Upgrading the mysql, I don't know. Because RPM probably is not creating the directory if it already existed, so I don't think it would change the context. Basically we have problems in the system if we upgrade policy with altered file_context, so the goal is to only update file_context on major upgrades (IE FC4, RHEL4). But since mysql was broken in FC3 we did not have this ability. Hopefully we will get better in the future. Dan
We are assuming unproven facts here --- namely that we know exactly which directory is being complained of. Tom, would you verify which directory that inode number refers to? Also, does Dan's proposed relabeling operation make the problem go away for you?
After updating to mysql-server-3.23.58-14 last night, mysqld wouldn't start. Here was the error I was getting in /var/log/messages: kernel: audit(1105113287.729:0): avc: denied { read } for pid=6777 exe=/usr/libexec/mysqld name=host.frm dev=ida/c0d0p2 ino=3883914 scontext=root:system_r:mysqld_t tcontext=root:object_r:var_lib_t tclass=file The corresponding message in /var/log/mysqld.log: 050107 5:29:50 /usr/libexec/mysqld: Can't find file: './mysql/host.frm' (errno: 13) After running the "rpm -q -l mysql-server mysql | restorecon -R -v -f -" command as suggested by dwalsh above, everything fired up just fine. I'm no selinux expert, but it seems as though it might be in that arena.
Was your mysql-server installation working before you did the update? I have a suspicion that people are seeing the "yum update" operation actually change the selinux context settings on /var/lib/mysql ... but dwalsh asserts that shouldn't be happening.
I guess I do assert it should not be happening. I do believe there is a bug in RPM right now that is not labeling files correctly that are being installed when run as a yum update. But we have not been able to lock it down. If this was working before and now it is not then I would say it might be a yum/rpm problem.
The installation was working fine before the update. After the update, mysqld failed to start until I ran the above command (rpm -q -l mysql-server mysql | restorecon -R -v -f). After the restorecon command, the newly installed update worked fine. Incidentally, I was having problems with squirrelmail, and being able to attach files. Squirrelmail was giving some error about not being able to move/copy the attachment. I ran the restorecon command (rpm -q -l squirrelmail | restorecon -R -v -f), and now the attachment problem I was having is gone, and things work great.
Tom, I don't know how to verify what file an inode refers to, I'm kinda a newb at this stuff... what command should I run.. After I ran the command suggested it does work fine now with setenforce set to 1. I didn't update with yum, I used up2date (just so you know)
find DIR -inum INODENUMBER -print should find it.
I've done all the sugested things : setenforce 0 rpm -q -l mysql-server mysql | restorecon -R -v -f - but I still get that error ? is there something that I am missing ?
If it fails under setenforce 0 then it's not a selinux issue. Maybe you should open a new bug and provide some actual details (like which package versions you're running and exactly what error you got from exactly what sequence of operations).
*** Bug 162123 has been marked as a duplicate of this bug. ***