Bug 840431 - mysqld-prepare-db-dir ignores User and Group settings
mysqld-prepare-db-dir ignores User and Group settings
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: mysql (Show other bugs)
16
x86_64 Linux
unspecified Severity medium
: ---
: ---
Assigned To: Tom Lane
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-07-16 07:26 EDT by David Waring
Modified: 2012-12-20 10:39 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-12-20 10:39:08 EST
Type: Bug
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 David Waring 2012-07-16 07:26:00 EDT
Description of problem:
The /usr/libexec/mysqld-prepare-db-dir script, as triggered by ExecStartPre=... in /lib/systemd/system/mysqld.service, has hardcoded user and group names throughout which may differ from user overrides in a /etc/systemd/system/mysqld.service file.

Also since "PermissionsStartOnly=yes" is not given in /lib/systemd/system/mysqld.service, then the /usr/libexec/mysqld-prepare-db-dir script will not execute as intended anyway.

Version-Release number of selected component (if applicable):
mysql-server-5.5.25a-1.fc16.x86_64

How reproducible:
Always

Steps to Reproduce:
1. Setup mysqld to run as a different user (as agreed in bug #661265)
2. "systemctl start mysqld.service" fails.
3.
  
Actual results:
Service fails to start because permissions are wrong.

Expected results:
File and Directory permissions should be set according to User and Group configured in the systemd service file, and the service should start without error.

Additional info:
I have done a work around by copying the mysqld-prepare-db-dir script and modifying the user name and group name where necessary and overriding the ExecStartPre in my local /etc/systemd/system/mysqld.service file to point at the new local copy (in /etc/systemd/libexec).

i.e. /etc/systemd/system/mysqld.service is now:
.include /lib/systemd/system/mysqld.service
[Service]
User=lmysql
Group=mysql
PermissionsStartOnly=true
ExecStartPre=/etc/systemd/libexec/mysqld-prepare-db-dir
Comment 1 Tom Lane 2012-07-16 09:46:33 EDT
We will not use PermissionsStartOnly, because that runs the script as root, which we are not going to do; the risk/benefit ratio just isn't good.  If you're obstinate enough to override that decision, I can't stop you, but it's not going to be the standard.

It could probably be made to work without that if you create and chown the data directory as root before running the command.  It's not clear to me exactly what if any setup you did before trying the failing case.

Having said that, I don't believe that the initscript version supported random choices of username either, and nobody complained about that in quite a few years.  What's the point of that exactly?
Comment 2 David Waring 2012-07-16 10:57:19 EDT
(In reply to comment #1)
> We will not use PermissionsStartOnly, because that runs the script as root,
> which we are not going to do; the risk/benefit ratio just isn't good.  If
> you're obstinate enough to override that decision, I can't stop you, but
> it's not going to be the standard.
> 
> It could probably be made to work without that if you create and chown the
> data directory as root before running the command.  It's not clear to me
> exactly what if any setup you did before trying the failing case.
> 
That was the point of the PermissionsStartOnly, then the StartPre script which creates the directories and log files can run as root to create and chown to the correct user before the main command is run as the configured user.

> Having said that, I don't believe that the initscript version supported
> random choices of username either, and nobody complained about that in quite
> a few years.  What's the point of that exactly?

That was the point of bug #661265 which was about the problems caused when trying to run mysql as another user (as configured in my.cnf). The resolution was to put the user configuration in the systemd .service file and put a comment in my.cnf pointing to instructions on using the systemd files. The reason behind #661265 was that mysqld running on the local machine couldn't use the "mysql" user as that was already defined as a network user, hence the need to define a different username.
Comment 3 Tom Lane 2012-07-16 11:36:01 EDT
Well, we do now have the technology to pull the user/group names out of the service file, so I'll see what I can do about making the script do that.  I'm not going to change the decision about PermissionsStartOnly though, as that would lose one of the major security advantages of systemd over the old initscript way.  Consider that what you're asking for is a root-privileged script that will change any random file it's pointed at to any random ownership it's told to.  Doesn't that sound a little dangerous?  Do you really want the ability to scribble on /etc/my.cnf to translate into total control of your system?

In short, I will make the script play along with a nondefault user name, but you're still going to have to initially create the data directory and log file with that ownership.  (Or I guess if you're brave, you could invoke the script manually as root.  But doing that on every system boot is just asking for trouble.)
Comment 4 David Waring 2012-07-17 09:23:08 EDT
I've been having a long think about the PermissionsStartOnly issue. I understand what you are saying, however since /etc/my.cnf is owned by root and isn't world writable it shouldn't be a problem since anyone who could write to /etc/my.cnf (or rename it and replace it with another file) could just as easily write or edit files in /etc/systemd/system and get those executing any arbitrary commands they like. Therefore what I think I'll do is a check to make sure that /etc/my.cnf is owned by root:root and isn't world writable before executing the prepare db script, just to be on the safe side.
Comment 5 Tom Lane 2012-07-17 10:58:42 EDT
You're right, it's not a huge problem as long as /etc/my.cnf is root-owned; which is a situation that was forced on us in the initscript world, precisely because anything weaker would have been a security hole.  But it would be much more desirable to let my.cnf be writable by group mysql, so that the database admin would not have to be given root privilege in order to make perfectly-legitimate database configuration changes.  To do that safely, we can't have anything that runs with root privs using my.cnf as input.

(Note: I'm not actually thinking of making my.cnf non-root-owned by default.  But I would like to have a situation where things are still secure if a particular installation tries to change that.  It was never really possible with initscripts, but under systemd it is.)
Comment 6 Fedora Update System 2012-09-30 01:05:51 EDT
mysql-5.5.28-1.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/mysql-5.5.28-1.fc17
Comment 7 Fedora Update System 2012-09-30 01:07:19 EDT
mysql-5.5.28-1.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/mysql-5.5.28-1.fc16
Comment 8 Fedora Update System 2012-09-30 01:07:41 EDT
mysql-5.5.28-1.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/mysql-5.5.28-1.fc18
Comment 9 Fedora Update System 2012-09-30 14:22:55 EDT
Package mysql-5.5.28-1.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing mysql-5.5.28-1.fc18'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-15119/mysql-5.5.28-1.fc18
then log in and leave karma (feedback).
Comment 10 Fedora Update System 2012-12-20 10:39:10 EST
mysql-5.5.28-1.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.

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