Bug 221085 - chown -R of the mysql data directory every startup
chown -R of the mysql data directory every startup
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: mysql (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Tom Lane
David Lawrence
Depends On:
  Show dependency treegraph
Reported: 2007-01-01 11:34 EST by Johnny Hughes
Modified: 2013-07-02 23:11 EDT (History)
4 users (show)

See Also:
Fixed In Version: RHSA-2008-0768
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-07-24 16:04:20 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Johnny Hughes 2007-01-01 11:34:02 EST
Description of problem:
The statement in the /etc/init.d/mysqld requires a significant time to execute
on every startup on servers with many mysql databases, and seems to not be
required unless there is a problem with items being created as another user:

chown -R mysql:mysql "$datadir"

Is this really necessary?  Should we not fix the underlying problem (if there is
one) of items not being created by the proper user, rather than the shotgun
approach of just changing everything at every startup?

The following bug was filed in the CentOS bugs database detailing this issue as

Comment 1 Tom Lane 2007-02-09 14:13:49 EST
Seems like it ought to be sufficient from a security perspective to chmod the
top directory, rather than -R every time.  Will fix in next turn (but I'm not
sure when that will be for the base RHEL4 mysql release).
Comment 3 Jerry Uanino 2008-01-15 13:50:18 EST
In addition, what happens if you are not running the server as mysql:mysql but
some other user.  This causes a problem in my environment because the init
script needs to be modified to prevent this from happening.  Maybe it should be
a seperate bug to read the mysql user from a config file?
Comment 4 Tom Lane 2008-01-15 20:12:22 EST
If you try to run it as some other user, you'll doubtless find that everything breaks --- for one thing the 
SELinux policy for mysqld will certainly not allow that.  I'm uninterested in trying to support such a case.
Comment 5 Jerry Uanino 2008-01-15 21:57:33 EST
I don't use selinux as it's not a requirement to run the OS.  I imagine selinux
would break if apache ran as some other user too, but there are certainly
implementations that require it in large enterprises.  In particular in
development environments we run various processes as different users. I'll
accept that not a lot of people don't do this and "uninterested" means not worth
the effort.
Comment 6 RHEL Product and Program Management 2008-02-01 14:10:49 EST
This request was evaluated by Red Hat Product Management for
inclusion, but this component is not scheduled to be updated in
the current Red Hat Enterprise Linux release. If you would like
this request to be reviewed for the next minor release, ask your
support representative to set the next rhel-x.y flag to "?".
Comment 12 errata-xmlrpc 2008-07-24 16:04:20 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


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