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?

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

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

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.

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

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

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

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

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

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.