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