Bug 141062 - mysql_install_db fails to install datbases under selinux
Summary: mysql_install_db fails to install datbases under selinux
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: mysql
Version: 3
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Tom Lane
QA Contact:
URL:
Whiteboard:
: 141434 162123 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-11-29 01:00 UTC by Mike Tremaine
Modified: 2013-07-03 03:03 UTC (History)
8 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2005-01-05 19:09:50 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
Patch to fix install_db and SELinux conflict. (716 bytes, text/plain)
2004-11-30 16:08 UTC, Daniel Walsh
no flags Details

Description Mike Tremaine 2004-11-29 01:00:05 UTC
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:

Comment 1 Daniel Walsh 2004-11-30 11:42:57 UTC
mysql-4.1.7-4 looks like it fixes this problem.

I am trying to get it updated for FC3.

Comment 2 Daniel Walsh 2004-11-30 16:08:25 UTC
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

Comment 3 Tom Lane 2004-11-30 17:55:07 UTC
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?

Comment 4 Daniel Walsh 2004-11-30 18:59:40 UTC
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

Comment 5 Tom Lane 2004-11-30 19:49:30 UTC
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.

Comment 6 Daniel Walsh 2004-11-30 20:57:40 UTC
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

Comment 7 Tom Lane 2004-11-30 21:12:40 UTC
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.

Comment 8 Daniel Walsh 2004-11-30 21:18:49 UTC
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.


Comment 9 Tom Lane 2004-11-30 21:45:16 UTC
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.

Comment 10 Bill Nottingham 2004-12-01 01:43:20 UTC
Adding bash package maintainer for possible comment.

Comment 11 Tim Waugh 2004-12-01 10:35:43 UTC
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.

Comment 12 Tom Lane 2004-12-01 15:10:22 UTC
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...

Comment 13 Daniel Walsh 2004-12-01 15:40:56 UTC
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

Comment 14 Tim Waugh 2004-12-01 16:45:10 UTC
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.

Comment 15 Daniel Walsh 2004-12-02 15:50:32 UTC
*** Bug 141434 has been marked as a duplicate of this bug. ***

Comment 16 Tom Lane 2004-12-09 21:21:06 UTC
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?

Comment 17 Daniel Walsh 2004-12-09 21:45:49 UTC
Does it have a database when you are finished?

Comment 18 Tom Lane 2004-12-09 22:13:36 UTC
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?

Comment 19 Daniel Walsh 2004-12-10 05:22:25 UTC
You got to the test in Enforcing mode.

setenforce 1


Comment 20 Tom Lane 2004-12-10 05:36:09 UTC
I did.

Comment 21 Noa Resare 2004-12-16 13:35:22 UTC
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!

Comment 22 Kees Kuip 2004-12-28 14:34:17 UTC
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.
 


Comment 23 Ed van Gasteren 2005-01-05 12:15:47 UTC
Because Tom Lane (tgl) 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) 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?




Comment 24 Ed van Gasteren 2005-01-05 13:41:24 UTC
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.

Comment 25 Daniel Walsh 2005-01-05 14:54:05 UTC
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

Comment 26 Tom Lane 2005-01-05 19:09:50 UTC
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.

Comment 27 Tom Christensen 2005-01-06 22:57:51 UTC
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

Comment 28 Daniel Walsh 2005-01-07 00:46:25 UTC
You need to relabel the package

rpm -q -l mysql-server mysql | restorecon -R -v -f -

Dan

Comment 29 Tom Lane 2005-01-07 15:11:11 UTC
Dan, shouldn't the RPM upgrade have done that automatically?

Comment 30 Daniel Walsh 2005-01-07 15:28:57 UTC
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

Comment 31 Tom Lane 2005-01-07 15:54:32 UTC
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?

Comment 32 J. Dilb 2005-01-07 16:30:57 UTC
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.

Comment 33 Tom Lane 2005-01-07 17:24:46 UTC
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.

Comment 34 Daniel Walsh 2005-01-07 17:56:41 UTC
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. 

Comment 35 J. Dilb 2005-01-08 20:50:24 UTC
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.


Comment 36 Tom Christensen 2005-01-09 01:58:03 UTC
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)

Comment 37 Daniel Walsh 2005-01-10 18:04:37 UTC
find DIR -inum INODENUMBER -print 

should find it.


Comment 38 Daniel Dumitrache 2005-02-19 14:36:40 UTC
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 ?

Comment 39 Tom Lane 2005-02-19 17:27:11 UTC
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).

Comment 40 Tom Lane 2005-10-25 01:02:13 UTC
*** Bug 162123 has been marked as a duplicate of this bug. ***


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