Bug #67672 new perl mysql_install_db fails when run as root with --user option
Submitted: 22 Nov 2012 0:00 Modified: 10 Jan 2013 14:24
Reporter: Hartmut Holzgraefe Email Updates:
Status: Duplicate Impact on me:
Category:MySQL Server: Installing Severity:S2 (Serious)
Version:5.6.8 OS:Linux
Assigned to: MySQL Verification Team CPU Architecture:Any
Tags: Contribution

[22 Nov 2012 0:00] Hartmut Holzgraefe
this code snippet totally does not what it is supposed to do:

  chown($opt->{user}, $dir) if -w "/" and !$opt->{user};

* Perl chown takes three parameters "$uid, $guid, @paths", not just two
* it expects numeric uid/gid (-1 for "do not change"), not username as text as given to the --user= option
* i don't get the "if the root dir is writeable" part ... is that a poor mans "only if run as root" check?
* "!$opt->{user}" is the wrong check, chown shall be executed if it is set, not if it's unset
* and there's no error checking for chown() failure, something the shell version checked for

How to repeat:
run as root:

  scripts/mysql_install_db --user=mysql

creating the ibdata1 file will fail with "permission denied" as the datadir will be created with owner:group root:root and rwx------ permissions while the bootstrap mysqld process runs with effective user id "mysql"

Suggested fix:
something like

  if ($opt->{user}) {
    my ($login,$pass,$uid,$gid) = getpwnam($opt->{user})
      or die "'".$opt->{user}."' not in passwd file";
    chown($uid, -1, $dir) or die "can't chown '$dir'";
[22 Nov 2012 1:18] MySQL Verification Team
Verified as described.

If you follow the instructions in INSTALL-BINARY:
shell> cd mysql
shell> chown -R mysql .
shell> chgrp -R mysql .
shell> scripts/mysql_install_db --user=mysql
shell> chown -R root .
shell> chown -R mysql data

The permissions work, but the error is masked.
[22 Nov 2012 3:10] MySQL Verification Team
Duplicate of internal bug:

[22 Nov 2012 12:31] MySQL Verification Team
The "check root dir is writable" part is a regression, see:
[23 Nov 2012 7:31] James Day
Thanks Hartmut, already being fixed based on our own checks. Looks as though the existing fix will be in the next build.
[10 Jan 2013 14:24] Erlend Dahl
This is a duplicate of an internally filed bug that was fixed in 5.6.9.