Bug 247923 - Unable to start MySQL after installation from RPMS due to AVC denials
Unable to start MySQL after installation from RPMS due to AVC denials
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: selinux-policy (Show other bugs)
7
All Linux
low Severity high
: ---
: ---
Assigned To: Daniel Walsh
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-07-11 21:00 EDT by Gerry Reno
Modified: 2007-11-30 17:12 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-07-12 13:13:08 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Gerry Reno 2007-07-11 21:00:13 EDT
Description of problem:   SELinux Problem:
Unable to start MySQL after installation of RPMS due to SELinux AVC denials

Version-Release number of selected component (if applicable):


How reproducible:
always

Steps to Reproduce:
1.  Install MySQL RPMS
2.  service mysql start
3.  see AVC denial for mysql.sock and others
  
Actual results:


Expected results:


Additional info:
Here is one of the AVC denial alerts:

Summary
    SELinux is preventing /usr/sbin/mysqld (mysqld_t) "create" to mysql.sock
    (var_lib_t).

Detailed Description
    SELinux denied access requested by /usr/sbin/mysqld. It is not expected that
    this access is required by /usr/sbin/mysqld 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
    Sometimes labeling problems can cause SELinux denials.  You could try to
    restore the default system file context for mysql.sock, restorecon -v
    mysql.sock If this does not work, there is currently no automatic way to
    allow this access. Instead,  you can generate a local policy module to allow
    this access - see http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385
    Or you can disable SELinux protection altogether. Disabling SELinux
    protection is not recommended. Please file a
    http://bugzilla.redhat.com/bugzilla/enter_bug.cgi against this package.

Additional Information        

Source Context                user_u:system_r:mysqld_t
Target Context                user_u:object_r:var_lib_t
Target Objects                mysql.sock [ sock_file ]
Affected RPM Packages         MySQL-server-5.1.20-0.glibc23 [application]
Policy RPM                    selinux-policy-2.6.4-23.fc7
Selinux Enabled               True
Policy Type                   targeted
MLS Enabled                   True
Enforcing Mode                Enforcing
Plugin Name                   plugins.catchall_file
Host Name                     grp-01-50-51
Platform                      Linux grp-01-50-51 2.6.21-1.3228.fc7 #1 SMP Tue
                              Jun 12 15:37:31 EDT 2007 i686 athlon
Alert Count                   37
First Seen                    Wed 11 Jul 2007 12:02:09 PM EDT
Last Seen                     Wed 11 Jul 2007 08:50:43 PM EDT
Local ID                      e25b070f-610b-47f2-a8cb-fc8570c04114
Line Numbers                  

Raw Audit Messages            

avc: denied { create } for comm="mysqld" egid=495 euid=496
exe="/usr/sbin/mysqld" exit=-13 fsgid=495 fsuid=496 gid=495 items=0
name="mysql.sock" pid=2672 scontext=user_u:system_r:mysqld_t:s0 sgid=495
subj=user_u:system_r:mysqld_t:s0 suid=496 tclass=sock_file
tcontext=user_u:object_r:var_lib_t:s0 tty=(none) uid=496
Comment 1 Daniel Walsh 2007-07-12 09:08:15 EDT
This looks like you have a labeling problem in /var/lib/mysql?

restorecon -R -v /var/lib/mysql

should fix this.

Any idea how this directory got created?  IE Did you delete the directory and
recreate it by hand?  rpm should have created the directory with the correct
context.
Comment 2 Gerry Reno 2007-07-12 12:22:13 EDT
This was in a brand new F7 installation that had mysql 5.0.37 installed but 
never used.  We did a 'yum remove mysql mysql-libs' which removed the 5.0.37 
version.  We then downloaded the SRPM from MySQL for version 5.1.20-0 and 
built a new set of RPMS.  We installed all of these RPMS but when the 
MySQL-server RPM tried to start MySQL it would not start.  Investigating the 
messages log we could see the AVC denial.  It is not clear whether the 
original 5.0.37 install or the new 5.1.20-0 install was responsible for 
setting the security contexts for /var/lib/mysql.  I would guess that it was 
probably the original 5.0.37.

The workaround that fixed this was to run '/sbin/fixfiles relabel'.  Now MySQL 
5.1.20-0 starts and behaves fine.

Comment 3 Daniel Walsh 2007-07-12 13:13:08 EDT
The restorecon call above would have fixed this also.  I have no idea why your
labeling got messed up.  If it happens again, please reopen the bug.

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