It sounds like a selinux issue, indeed ... but you have not provided either mysql or selinux package 
version numbers so there's not much hope of giving specific information.

I'd suggest updating both of those packages to latest available versions and doing "restorecon -R /var/
lib/mysql" to be sure that everything in that directory is properly labeled.

I tried the restorecon command - but it didn't help!

Both server and client are in version mysql-3.23.58-16.FC3.1
The selinux-policy is in version selinux-policy-targeted-1.17.30-2.93

=> the system is up2date.

I am updating my system as soon as the updates are released. I've had this
problem for a long time. It's not a problem that came with the last update.

Actually, looking closer at the /var/log/messages entry, it seems to be
complaining about a directory named "lib", which suggests that the bogus selinux
setting may actually be on /var/lib.  Or maybe somewhere else ... the inode
number is the only definitive indication there.  Anyway, find the directory with
inode 240482 and try a restorecon on that.

I did a

restorecon -R /var

Unfortunately with no success. Where else can be something called "lib" which
mysqld wants to access? According to /var/log/mysqld.log access to
/var/lib/mysql was refused, which caused it to terminate.

In the hope that this is the instance which controls the access, I post you both my 
/etc/selinux/targeted/src/policy/file_contexts/program/mysqld.fc
and my
/etc/selinux/targeted/src/policy/domains/program/mysqld.te


##################################################

# mysql database server
/usr/sbin/mysqld(-max)? --      system_u:object_r:mysqld_exec_t
/usr/libexec/mysqld     --      system_u:object_r:mysqld_exec_t
/var/run/mysqld(/.*)?           system_u:object_r:mysqld_var_run_t
/var/log/mysql.*        --      system_u:object_r:mysqld_log_t
/var/lib/mysql(/.*)?            system_u:object_r:mysqld_db_t
/var/lib/mysql/mysql\.sock -s   system_u:object_r:mysqld_var_run_t
/etc/my\.cnf            --      system_u:object_r:mysqld_etc_t
/etc/mysql(/.*)?                system_u:object_r:mysqld_etc_t
ifdef(`distro_debian', `
/etc/mysql/debian-start --      system_u:object_r:bin_t
')


##################################################
And here is my  /etc/selinux/targeted/src/policy/domains/program/mysqld.te
##################################################



#DESC Mysqld - Database server
#
# Author:  Russell Coker <russell.au>
# X-Debian-Packages: mysql-server
#

#################################
#
# Rules for the mysqld_t domain.
#
# mysqld_exec_t is the type of the mysqld executable.
#
daemon_domain(mysqld)

type mysqld_port_t, port_type;
allow mysqld_t mysqld_port_t:tcp_socket name_bind;

allow mysqld_t mysqld_var_run_t:sock_file create_file_perms;

etcdir_domain(mysqld)
typealias mysqld_etc_t alias etc_mysqld_t;
type mysqld_db_t, file_type, sysadmfile;

log_domain(mysqld)

# for temporary tables
tmp_domain(mysqld)

allow mysqld_t usr_t:file { getattr read };

allow mysqld_t self:fifo_file { read write };
allow mysqld_t self:unix_stream_socket create_stream_socket_perms;
allow initrc_t mysqld_t:unix_stream_socket connectto;
allow initrc_t mysqld_var_run_t:sock_file write;

allow initrc_t mysqld_log_t:file { write append setattr ioctl };

allow mysqld_t self:capability { dac_override setgid setuid net_bind_service };
allow mysqld_t self:process getsched;

allow mysqld_t proc_t:file { getattr read };

# Allow access to the mysqld databases
create_dir_file(mysqld_t, mysqld_db_t)
allow mysqld_t var_lib_t:dir { getattr search };

can_network(mysqld_t)
can_ypbind(mysqld_t)

# read config files
r_dir_file(initrc_t, mysqld_etc_t)
allow mysqld_t { etc_t etc_runtime_t }:{ file lnk_file } { read getattr };

allow mysqld_t etc_t:dir search;

read_sysctl(mysqld_t)

can_unix_connect(sysadm_t, mysqld_t)

# for /root/.my.cnf - should not be needed
allow mysqld_t sysadm_home_dir_t:dir search;
allow mysqld_t sysadm_home_t:file { read getattr };

ifdef(`logrotate.te', `
r_dir_file(logrotate_t, mysqld_etc_t)
allow logrotate_t mysqld_db_t:dir search;
allow logrotate_t mysqld_var_run_t:dir search;
allow logrotate_t mysqld_var_run_t:sock_file write;
can_unix_connect(logrotate_t, mysqld_t)
')

ifdef(`user_db_connect', `
allow userdomain mysqld_var_run_t:dir search;
allow userdomain mysqld_var_run_t:sock_file write;
')

ifdef(`daemontools.te', `
domain_auto_trans( svc_run_t, mysqld_exec_t, mysqld_t)
allow svc_start_t mysqld_t:process signal;
svc_ipc_domain(mysqld_t)
')dnl end ifdef daemontools

ifdef(`distro_redhat', `
allow initrc_t mysqld_db_t:dir create_dir_perms;

# because Fedora has the sock_file in the database directory
file_type_auto_trans(mysqld_t, mysqld_db_t, mysqld_var_run_t, sock_file)
')

Dan, do you have any idea what's going on here?  What could selinux be
complaining about, if not /var/lib?

Looks like the mysql is trying to look in the directory you are currently
running in.
allow mysqld_t home_root_t:dir search;

So you attempted to run this app from the /root directory and then it tried to
chroot but failed.

If you add the above rule does it work?

"So you attempted to run this app from the /root directory and then it tried to
chroot but failed."

I've run the start skript in /etc/init.d

"If you add the above rule does it work?"

Which rule do I have to add and how do I add rules?

I have added your rule to /etc/selinux/targeted/src/policy/domains/program/mysqld.te

I rebooted the machine, unfortunately with no success, sorry!

What else do you need to know, to solve this problem?



Btw. I have worked on another FC3 machine today. I installed mysql and
mysql-server (with some perl packages, which these packages depend on) and it
worked !! Is it possible, that I have misconfigured something?

greets Boris

Well the AVC message you gave above says that mysql went searching for something
in the root directory.  So it is likely that something is screwed up.
Is mysqld attempting to run as root?

Here is my /etc/my.cf

According to this file, it tries to run as user mysql. How can I check, which
user it actually uses?

# cat /etc/my.cnf
[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock

[mysql.server]
user=mysql
basedir=/var/lib

[safe_mysqld]
err-log=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid

Hi,

I have spent some time learning a bit about selinux.

The proble here seems to be the directory /var/lib:

$ ls -lZ /var | grep lib
drwxr-xr-x  root     root     system_u:object_r:home_root_t    lib

This directory also has the inode numer 240482, which is mentioned in the "avc
denied" output:
$ ls -li /var | grep lib
240482 drwxr-xr-x  29 root    root    4096  5. Apr 23:11 lib

I have found the following line in
/etc/selinux/targeted/src/policy/file_contexts/file_contexts:
/var/lib            -d      system_u:object_r:home_root_t

The strange thing is the home_root_t domain, this directory belongs to!? Is this
normal? I have never changed anything in this file.

There are many other processes, which cannot access this directory,too: dhcpd
and ntpd

What would you suggest to do?

greets Boris

Btw.: The fact that mysql worked on another fc3 machine, as I've reported above,
is only the have truth. The machine I was talking about has selinux disabled.

Ok the problem is that you have a user account that is in the /var directory. 
This is screwing up the labeling.   /var should be var_t.  In FC3 we have a
problem handling useraccounts with UID > 500 in the /var directory.

Could you check if this is the case.

Dan

I have I user "ogo", for opengroupware.org with the uid 500 and the home
directory /var/lib/opengroupware.org

This might be the reason!!

Is it enough to set the line in
/etc/selinux/targeted/src/policy/file_contexts/file_contexts to the correct
value, or do I have to "compile" the rules first?

thanks Boris

There's another strange thing:

I understand, that the labeling is wrong, but how can the settings in
/etc/selinux/targeted/src/policy/file_contexts/file_contexts be screwed up? Are
these files edited automatically by any instance?

Yes, genhomedircon generates these entries.  Do you need to login or does the
app need a login to ogo.  IE Can you change the shell to /sbin/nologin

I set ogo's home to /home/ogo (and created this dir before of course) and ran 

restorecon -R /

It worked then for me. It's obviously not a mysql bug, but it's an ugly selinux bug.
What's the procedure now in this case!

greets Boris

policycoreutils-1.18.1-2.12 Just went out to fedora-testing should fix this problem.

Available on ftp://people.redhat.com:dwalsh/SELinux/FC3