MySQL Bugs: #35203: The installer failed to change file privilege on mysql directory on MacOS X

Bug #35203	The installer failed to change file privilege on mysql directory on MacOS X
Submitted:	11 Mar 2008 3:25	Modified:	17 Aug 2010 10:38
Reporter:	Mikiya Okuno	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Enterprise Monitor: Installing	Severity:	S2 (Serious)
Version:	1.3.0.8939	OS:	MacOS (Darwin Kernel Version 9.2.0)
Assigned to:	BitRock Merlin	CPU Architecture:	Any

Description:
The MEM installer fails to change privilege of the files under the 'mysql' directory under the MEM installation directory: /Applications/mysql/enterprise/monitor/mysql

The installer firstly change the owner from the current log-in user to mysql user, then attempt to change privileges. But this will fail because the installer runs with current log-in user privileges and it doesn't have any privileges for mysql user any more.

How to repeat:
Run mysqlmonitor-1.3.0.8939-osx-installer.app using non-root user account.

Suggested fix:
Let MEM installer change the owner after all privilege operations are done.

Sorry, we have reviewed the installer logic and we haven't found (nor experienced in the past) the behavior that you report. Which is the exact error that you are getting? Here is a little pseudo-code summary of the actions executed by the MEM installer regarding ownership / permissions for the MySQL database installed with MEM:

chmod 0777 ${installdir}/mysql/tmp
if <user is root user> {
  chown -R root ${installdir}/mysql
  chown -R mysql ${installdir}/mysql/data
  chgrp -R mysql ${installdir}/mysql
}

As you can see, permissions are granted to the mysql/tmp folder in all cases, but ownership changes are only performed for root user installations, and after the permissions operation has taken place.

After we perform those operations, we invoke mysql_install_db. Is it possible that this install script also deals with ownership / permissions?

No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".

With MEM version 2.0.0.6072, and logged in as a non-root user during installation, the /Applications/mysql/enterprise/monitor/mysql folder is owned by the user that installed the monitor.

Hi Marcos,

I confirmed the problem again.

It's true that the mysql data directory is owned by the user who installed it. However, mysqlmonitorctrl.sh attempts to start mysqld using "mysql" user instead of the user who installed it. I had installed MEM using another user while I have the user named "mysql" separately. I mean I installed the user "mikiya".

Then, of course, mysqld failed to start. So I changed the owner of the directory from mikiya to mysql. This could be the cause of the problem.

I guess that the user name in the mysqlmonitorctrl.sh is wrong. Please try to install it using another user into the system which has the user named mysql.

No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".

The installer *should* use an existing or new application-specific restricted privileges user (no login) for both mysqld and tomcat, just like the "standard" installer for mysql does, i.e. it uses the "_mysql" user to launch mysqld, and "_mysqld" owns the data directory.

Let's:

1. require a user with admin privileges
2. make it install the same way that mysql server installs from the DMG package

Andy Bang writes: 
Based on input from MarkL and MarkM, here's how we want to resolve this:

If installing in GUI mode:

  o Require that it be done by the root user
  o Prompt for the root user password and switch to root if the
    installer detects that it was not started as root

If installing in text mode:

  o Show the following "soft" warning message on screen if the
    installer detects that it was not started as root:

    "For security reasons it is best to run the MySQL server that is
     used by the Service Manager as the pre-installed mysql user.  You
     are installing the server as a non-root user, so the ownership of
     the MySQL data directory cannot be granted to the mysql user,
     which means you will only be able to start the server as the
     current user unless you manually grant ownership to the mysql
     user at a later time.  We recommend canceling installation at
     this point and re-starting it as the root user."

Should we fix this issue only on OS X or should we follow the same approach for Linux and Solaris platforms?

Patch sent to Keith.

Andy Bang writes: 
In build 2.2.2.1722.

Marcos Palacios writes: 
With build 2.2.1.1722 (which is 2.2.2) on Mac OS X:
- if I attempt a GUI install by double-clicking on the installer file, it first requests the root password. When I enter it, the install proceeds BUT when it gets to the post-install step, it gives an error. See the two screenshots attached below.
However:
- if I attempt a GUI install by typing the following command on a terminal, at the directory where the installer file is:
   $ sudo mysqlmonitor-2.2.1.1722-osx-installer.app/Contents/MacOS/osx-intel
  and enter the root password, then the install proceeds and completes without any errors.



Attachment: 10392_MEM2.2systPass.png (image/png, text), 26.24 KiB.



Attachment: 10393_MEM2.2install.png (image/png, text), 70.47 KiB.

Andy Bang writes: 
A Mac user would expect this to work by supplying root credentials when prompted by the installer, and not have to use the sudo workaround. Is the installer passing the root credentials to the scripts it calls as part of the installation process? That may be the solution to this problem.

Patch sent to Andy.

Andy Bang writes: 
Patch from BitRock committed to source control for 2.2 and 2.3 codelines.

Marcos Palacios writes: 
This fix has been verified in Monitor build 2.3.0.2010 running the installer via the GUI on Mac OS X 10.5.8.

Per BitRock,

The problem is that the Administrator and root environments are different on OS X and it is necessary to specify the temporary dir.  So the following was added to my.cnf/my.ini:

tmpdir = @@BITROCK_MYSQL_ROOTDIR@@/tmp



Attachment: 10396_MEM2.3uninstall061810.png (image/png, text), 49.40 KiB.



Attachment: 10397_bitrock_debug_98304.xml (text/xml), 3.72 KiB.



Attachment: 10398_bitrock_installer_98304.log (text/plain), 421.31 KiB.

Hi Andy,

There are two different issues reported in this post.

The first is related to the "tmpdir" line in the my.ini/my.cnf file. The problem is that the upgrade installer does not have this line in the my.ini/my.cnf file. On Windows the "{installdir}/mysql/tmp" folder does not exist so it should be necessary to create it. Our suggestion is to remove this line from the my.ini/my.cnf file for all platforms and set the "TMPDIR" environment variable on OS X to "/tmp" folder during the installation. We have checked this solution and it works well. Please let us know if this approach is valid for you.

The second issue is that the uninstaller preserves the previous owner. We are working to fix it.

Patch setn to Andy. This path fixes both issues, the "tmpdir" line in the my.ini/my.cnf and the uninstaller wrong owner.

Marcos Palacios writes: 
Verified fixed in Monitor build 2.2.2.1728:
 - the tmpdir parm in my.cnf is no longer used,
 - the uninstaller (after an upgrade) requires root password even if the original install was done as non-root.

Marcos Palacios writes: 
Verified fixed in Monitor build 2.3.0.2011 on Mac OS X. 
It has been tested OK on Windows. Will test the result on linux now.

Marcos Palacios writes: 
Testing build 2.2.2.1728 on linux (FC 6) was done as follows (must be root):

1. Full install
    - this works OK as long as the installation dir is under /opt/...
    - if we use a dir under /home/... then we have errors, but this is not customary. *I do not think this is an issue.*

2. Upgrade install  (both cases with the initial state that the current monitor is MEM 2.1.2.1163)
    a) current monitor was installed as non-root in a dir under /home/...
        - the upgrade installer completes but the dashboard does not start (it gets a 'HTTP Status 404' on the browser)
        - has the same errors as shown in the "19/Jun/10 12:43 AM" comment above, part "2"
        - am checking with mtx about this issue
    b) current monitor was installed as root in a dir under /opt/...
        - this works OK

Mark Leith writes: 
OK, you are getting permission denied errors when trying to start the instance.

Please get ls -l output for the mysql dir (and it's sub dirs, specifically the data and tmp dirs), both before and after the upgrade.

Marcos Palacios writes: 
1) before the upgrade

[marcos@localhost ~]$ cd mysql/enterprise/monitor/
[marcos@localhost monitor]$ ls -al
total 3240
drwxrwxr-x  9 marcos marcos    4096 Jun 25 06:41 apache-tomcat
-rw-------  1 marcos marcos     422 Jun 25 06:42 configuration_report.txt
drwxr-xr-x  3 marcos marcos    4096 Jun 25 06:42 etc
drwxrwxr-x  2 marcos marcos    4096 Jun 25 06:42 images
drwxrwxr-x  8 marcos marcos    4096 Jun 25 06:41 java
drwxrwxr-x  2 marcos marcos    4096 Jun 25 06:42 licenses
drwxrwxr-x 13 marcos marcos    4096 Jun 25 06:42 mysql
-rwxr--r--  1 marcos marcos    8332 Jun 25 06:42 mysqlmonitorctl.sh
-rw-rw-r--  1 marcos marcos   11025 May 12 14:20 README_en.txt
-rw-rw-r--  1 marcos marcos   13376 May 12 14:20 README_ja.txt
drwxrwxr-x  2 marcos marcos    4096 Jun 25 06:42 support-files
-rwx------  1 marcos marcos 3189228 Jun 25 06:43 uninstall
[marcos@localhost monitor]$ cd mysql
[marcos@localhost mysql]$ ls -al
total 128
drwxrwxr-x  2 marcos marcos 4096 Jun 25 06:42 bin
drwxrwxr-x  4 marcos marcos 4096 Jun 25 06:43 data
drwxrwxr-x  2 marcos marcos 4096 Jun 25 06:41 docs
drwxrwxr-x  2 marcos marcos 4096 Jun 25 06:41 include
-rw-rw-r--  1 marcos marcos 8768 Aug  4  2009 INSTALL-BINARY
drwxrwxr-x  3 marcos marcos 4096 Jun 25 06:42 lib
-rw-rw-r--  1 marcos marcos  718 Aug  4  2009 LICENSE.mysql
drwxrwxr-x  4 marcos marcos 4096 Jun 25 06:41 man
-rw-rw-r--  1 marcos marcos 1270 Jun 25 06:42 my.cnf
-rw-rw-r--  1 marcos marcos 1873 Aug  4  2009 README
drwxrwxr-x  2 marcos marcos 4096 Jun 25 06:42 scripts
drwxrwxr-x 27 marcos marcos 4096 Jun 25 06:42 share
drwxrwxr-x  5 marcos marcos 4096 Jun 25 06:41 sql-bench
drwxrwxr-x  2 marcos marcos 4096 Jun 25 06:42 support-files
drwxrwxrwx  2 marcos marcos 4096 Jun 25 06:43 tmp
[marcos@localhost mysql]$  ls -al tmp
total 4
srwxrwxrwx 1 marcos marcos 0 Jun 25 06:43 mysql.sock
[marcos@localhost mysql]$ ls -al bin
total 56644
-rwxr-xr-x 1 marcos marcos  1840136 Aug  4  2009 my_print_defaults
-rwxr-xr-x 1 marcos marcos  4946966 Aug  4  2009 mysql
-rwxr-xr-x 1 marcos marcos  4324351 Aug  4  2009 mysqladmin
-rwxr-xr-x 1 marcos marcos  4739544 Aug  4  2009 mysqlbinlog
-rwxr-xr-x 1 marcos marcos  4311126 Aug  4  2009 mysqlcheck
-rwxr-xr-x 1 marcos marcos 29506824 Aug  4  2009 mysqld
-rwxr-xr-x 1 marcos marcos    17008 Jun 25 06:42 mysqld_safe
-rwxr-xr-x 1 marcos marcos  4464602 Aug  4  2009 mysqldump
-rwxr-xr-x 1 marcos marcos  1895441 Aug  4  2009 mysql_upgrade
-rwxr-xr-x 1 marcos marcos  1789503 Aug  4  2009 resolveip
[marcos@localhost mysql]$

2) after the upgrade

[root@localhost monitor]# pwd
/home/marcos/mysql/enterprise/monitor
[root@localhost monitor]# ls -al
total 3620
drwxrwxr-x  9 root root     4096 Jun 25 06:59 apache-tomcat
drwxr-xr-x  9 root root     4096 Jun 25 06:58 backup
-rw-------  1 root root      439 Jun 25 07:00 configuration_report.txt
drwxr-xr-x  3 root root     4096 Jun 25 06:42 etc
drwxrwxr-x  2 root root     4096 Jun 25 07:00 images
drwxrwxr-x  8 root root     4096 Jun 25 06:59 java
drwxrwxr-x  2 root root     4096 Jun 25 07:00 licenses
drwxrwxr-x 13 root mysql    4096 Jun 25 07:00 mysql
-rwxr--r--  1 root root     8332 Jun 25 07:00 mysqlmonitorctl.sh
-rw-rw-r--  1 root root    11642 Jun 22 12:18 README_en.txt
-rw-rw-r--  1 root root    13439 Jun 22 12:18 README_ja.txt
drwxrwxr-x  2 root root     4096 Jun 25 07:00 support-files
-rwx------  1 root root  3569730 Jun 25 07:01 uninstall
[root@localhost monitor]# cd mysql
[root@localhost mysql]# ls -al
total 188
drwxrwxr-x  2 root  mysql  4096 Jun 25 07:00 bin
drwxrwxr-x  4 mysql mysql  4096 Jun 25 07:00 data
drwxrwxr-x  2 root  mysql  4096 Jun 25 06:41 docs
drwxrwxr-x  2 root  mysql  4096 Jun 25 07:00 include
-rw-rw-r--  1 root  mysql  9439 Feb  4 11:24 INSTALL-BINARY
drwxrwxr-x  3 root  mysql  4096 Jun 25 07:00 lib
-rw-rw-r--  1 root  mysql   718 Feb  4 11:24 LICENSE.mysql
drwxrwxr-x  4 root  mysql  4096 Jun 25 06:41 man
-rw-rw-r--  1 root  mysql  1290 Jun 25 07:00 my.cnf
-rw-r--r--  1 root  mysql  1087 Jun 25 07:00 my.cnf_comparison_report.txt
-rw-rw-r--  1 root  mysql  1289 Jun 25 07:00 my-default.cnf
-rw-rw-r--  1 root  mysql 47602 Feb  4 11:24 README
drwxrwxr-x  2 root  mysql  4096 Jun 25 07:00 scripts
drwxrwxr-x 27 root  mysql  4096 Jun 25 07:00 share
drwxrwxr-x  5 root  mysql  4096 Jun 25 06:41 sql-bench
drwxrwxr-x  2 root  mysql  4096 Jun 25 07:00 support-files
drwxrwxrwx  2 root  mysql  4096 Jun 25 07:00 tmp
[root@localhost mysql]# ll tmp
total 0
[root@localhost mysql]# ls -al bin
total 53368
-rwxr-xr-x 1 root mysql   487773 Feb  4 11:24 my_print_defaults
-rwxr-xr-x 1 root mysql  4952905 Feb  4 11:24 mysql
-rwxr-xr-x 1 root mysql  4327904 Feb  4 11:24 mysqladmin
-rwxr-xr-x 1 root mysql  4743489 Feb  4 11:24 mysqlbinlog
-rwxr-xr-x 1 root mysql  4314327 Feb  4 11:24 mysqlcheck
-rwxr-xr-x 1 root mysql 30217873 Feb  4 11:24 mysqld
-rwxr-xr-x 1 root mysql    17008 Jun 25 07:00 mysqld_safe
-rwxr-xr-x 1 root mysql  4468535 Feb  4 11:24 mysqldump
-rwxr-xr-x 1 root mysql   543293 Feb  4 11:24 mysql_upgrade
-rwxr-xr-x 1 root mysql   399597 Feb  4 11:24 resolveip
[root@localhost mysql]#

Hi,

We can not reproduce this issue on our side and the permissions are correct. Could you check if there is any firewall or SELinux enabled? I can see the following in the log file that you posted:

100618 12:02:41 [ERROR] Can't start server : Bind on unix socket: Permission denied
100618 12:02:41 [ERROR] Do you already have another mysqld server running on socket:
/home/marcos/mysql/enterprise/monitor/mysql/tmp/mysql.sock ?

Could you check if this socket exists?

Diego Medina writes: 
See http://bugs.mysql.com/bug.php?id=54956

=============

On a clean mac 10.5

================

THe installer 2.3.0.2018 (when running with sudo) tries to use the mysql user, but on mac
 (10.5 at least) there is not such user, mac comes with a _mysql user

So the installer fails.

cat /etc/passwd  | grep mysql
_mysql:*:74:74:MySQL Server:/var/empty:/usr/bin/false

============

I get this on the terminal:

Problem running post-install step. Installation may not complete correctly
 Error running
/Applications/mysql/enterprise/2.3/monitor-2.3.0.2018/mysql/scripts/mysql_install_db
--defaults-file=/Applications/mysql/enterprise/2.3/monitor-2.3.0.2018/mysql/my.cnf
--user=mysql : chown: mysql: Invalid argument
chown: mysql: Invalid argument
chown: mysql: Invalid argument
100702  7:10:16 [ERROR] Fatal error: Can't change to run as user 'mysql' ;  Please check
that the user exists!

100702  7:10:16 [ERROR] Aborting

100702  7:10:16 [Note]
/Applications/mysql/enterprise/2.3/monitor-2.3.0.2018/mysql//bin/mysqld: Shutdown
complete

As you can see above in this bug report, the solution as currently implemented has created a number of problems.  So we'd like to essentially start over and use the approach described below.  Note that we are NOT requiring installation as root, nor are we asking for root credentials.

1) Install everything as the current user (i.e. like we did before we
   started working on this bug) - do NOT require installation as root.

   o Ensure that the current user has write access to the directory
     specified on the "Installation Directory" screen before
     proceeding from that screen.

2) Add a new screen called "Service Configuration" (after the
   "Installing" screen and before the "Completed Installing Files"
   screen), as follows:

   -------------------------------------------------------------
   | Do you want the Monitor's services to be automatically    |
   | started when this machine is booted (this requires        |
   | root, sudo, or Administrative privileges)?                |
   |                                                           |
   | [x] Yes, I want the services to be started automatically  |
   |                                                           |
   | [ ] No, I will start them manually as needed              |
   -------------------------------------------------------------

3) If the user says "Yes" (the default):

  o Include --user=mysql in mysqlmonitor.sh where the MySQL server is
    started (note that it's --user=_mysql on Mac OS X; see Bug #54956
    - Installer uses user mysql instead of _mysql on mac)

  o Create (but don't run) a shell script called root.sh that does the
    following:

       chown -R root ${installdir}/mysql
       chown -R mysql ${installdir}/mysql/data
       chgrp -R mysql ${installdir}/mysql
       
       copies the etc/init.d file to the right place
       
       runs mysqlmonitor.sh to start the services

   o Display a message to the user as follows:
   
     --------------------------------------------------------------
     | The following configuration script needs to be executed as |
     | the "root" user:                                           |
     |                                                            |
     |   <path>/root.sh                                           |
     |                                                            |
     | To execute the configuration script:                       |
     |                                                            |
     |   1) Open a terminal window                                |
     |   2) Log in as "root" (or use sudo)                        |
     |   3) Run the script                                        |
     |   4) Return to this window and click "Next" to continue    |
     --------------------------------------------------------------
   
   o The idea is to avoid collecting root credentials, and avoid
     worrying about whether root is used on some systems, but sudo on
     others.  This is how Oracle does things (see
http://www.oracle.com/technology/obe/11gr1_db/install/dbinst/dbinst.htm).

   o If you detect that they're installing as root (as will probably
     often be the case on Windows and may be the case on other
     systems), just go ahead and run the script for them rather than
     displaying the message.

4) If the user says "No":
   
   o Do not include --user=mysql when starting the MySQL server in
     mysqlmonitor.sh (or include --user=<currentuser>, whichever is
     easier for you).
   
   o Run mysqlmonitor.sh as the current user when they click "Next".

5) Also, please note the following:

   o Do *not* switch to the root user to install everything as is
     currently done; install all files as the current user.

   o Do not set root ownership for all other areas of the application.

   o Continue to set the file permissions as we have decided in other
     bugs for security issues

Hi Andy,

We noticed that the "root.sh" script it is not simple and it could create more problems in the future. This script should run the following actions on all platforms that we currently support:

- Create the mysql user if it does not exist.
- Change mysql folder permissions.
- Install the service using update-rc.d on Debian distributions, chkconfig on RedHat and SuSE distros, launchctl on OS X or creating the links directly on Solaris platforms.

We implemented this logic in the XML files and is InstallBuilder itself who takes care of most of the differences.  It could take some time to move all this logic to a bash script that works in all platforms. A possible solution is to create an InstallBuilder binary called "root.bin" which reuse the implemented code instead of a bash script. Is this solution valid for you? If you prefer you can also implemented this script on your side.

Regards,

Beltran

Beltran,

We are taking your comments under consideration and hope to have a response soon.

In the meantime, though, the current state of the installer with the fixes we previously asked for in 35203 is less desirable than it was before we started working on this.  So can you please ASAP revert to how things were done before we started addressing this issue?  In other words, revert to the pre-35203 state, but retain any other fixes that have been made to address other issues besides this one.

Please let me know when you can deliver that.

Thanks,

Andy

Per Andy request we reverted the changes that we did to fix this issue. Now it is not necessary to install the Stack as root user.

Andy Bang writes: 
In build 2.2.2.1729.

See "IMPORTANT NOTE TO QA" above!

Marcos Palacios writes: 
Tested with Monitor build 2.2.2.1729 on Mac OS X and verified the installer works as it did before.

Tested with Monitor build 2.2.2.1729 on MS Windows XP and verified the installer works as it did before.

Marcos Palacios writes: 
Per above request.

Patch sent to Andy.

A note has been added to the 2.2.3 and 2.3.0 changelog: 

        The file permissions on the <filename>mysql</filename>                                                                                             
        directory within the &merlin_server; installation would not be                                                                                     
        set correctly on Mac OS X.