Skip to content

Prevent root password from being accessible by normal users on first run #53

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 8 commits into from
Jun 3, 2015

Conversation

ltangvald
Copy link
Collaborator

The first time the server was started, the file containing the root password in plaintext would be readable by any user on the database (and the filename listed in the variable list).

We changed the first run to do the initialization separately, then restart the server.

fi

chown -R mysql:mysql "$DATADIR"

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Permissions are now only set during initialization. Would this be a problem when using an already initialized data-dir (e.g. bind-mounted)?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, it almost certainly will. The line should have been copied instead of moved. Thanks :)

@md5
Copy link

md5 commented Mar 8, 2015

If I understand this correctly, the issue is that the file /tmp/mysql-first-time.sql can be read by any user who can connect to the database by using LOAD DATA INFILE. In order to do that, the user would have to have the FILE permission granted on some table in the database. Is that right?

I tried changing the permissions on the file to 0400 in the hope that MySQL would read it as root before dropping privileges to the mysql user, but that was not the case.

One thing I don't like about the entrypoint changes is the fact that mysqld is started and backgrounded in the middle of the initialization. It would be good if there were a more graceful way to achieve the same fix.

On a side note, it looks like the branch you're using has other changes in it that are unrelated to the password fix (e.g. the removal of Perl for the 5.7 Dockerfile). Those changes should probably go in a separate PR.

@md5
Copy link

md5 commented Mar 8, 2015

P.S. It's really cool to see this PR coming from the mysql/docker repo. It would be great to see more official images taken over by the upstream teams.

@ltangvald
Copy link
Collaborator Author

Is the desired procedure to only have a single commit, or just no unrelated features? The perl dependency change could be removed, but the others are bug fixes.

With regards to the server run in init, I agree it's fairly ugly, but don't really know a more graceful way to do it. We do have suggestions on features that would help, such as single user mode, but the server doesn't currently support it.

@md5
Copy link

md5 commented Mar 9, 2015

I mainly suggested breaking out the Perl change because it looks like something that can be merged without much discussion, whereas I think sorting out this MYSQL_ROOT_PASSWORD thing may take a bit more time (given stuff like the backgrounded mysqld).

If you think any of the other fixes are unambiguous bugs that can be easily merged after a short discussion, I'd probably break those into their own PRs too (or possibly combine them with the Perl change).

@ltangvald
Copy link
Collaborator Author

The bugfixes are related to the security issue, so they need to be included. We'll separate the Perl change, though.

@ltangvald
Copy link
Collaborator Author

Removed the perl change.

While the system of starting and restarting the server is clunky, it does have the benefit of making it easier to support features such as those requested in issue #24 and pull request #18 without using --bootstrap or --init-file, which have their own problems.

local section=$1
local option=$2
local default=$3
ret=$(/usr/local/mysql/bin/my_print_defaults $section | grep '^--'${option}'=' | cut -d= -f2-)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not just rely on the PATH for finding the right my_print_defaults binary?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, that should work better.

@tianon
Copy link
Member

tianon commented Mar 11, 2015

+1 to being able to solve things like #24 in a clean way -- this was the solution we were considering for that, but were having trouble bringing ourselves to actually start up and background mysqld just to talk to it for a little bit, shut it down, and then start it back up again.

@tianon
Copy link
Member

tianon commented Mar 11, 2015

The whitespace in this PR seems to be all over the place -- some places it's a tab (like it was originally in these files), but some places it's a 4-space indent or stranger incantations. 😄

@ltangvald
Copy link
Collaborator Author

Whitespace issue is my bad. Managed to set up my editor and git so I missed the issue :)


SOCKET=$(get_option mysqld socket "/tmp/mysql.sock")
HOSTNAME=$(hostname)
PIDFILE=$(get_option mysqld pid-file "$DATADIR/$HOSTNAME.pid")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What I meant with my comment on this line before is why are we bothering with HOSTNAME here at all? The "hostname" in our container is likely to be something random like 9d3cb2141e44, so why not just go with something like mysql.pid and make sure it's deleted appropriately before we start up mysqld?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, it's probably a better idea to specify the pid-file instead of doing it like this.

@ltangvald
Copy link
Collaborator Author

The 5.7.6+ issue wasn't given very high priority before we started the work with Docker, but it's a bigger problem here because of the way we use the --verbose --help command to fetch options. We're looking into ways to handle it, but at least it's not an issue on Debian right now :)

@tianon
Copy link
Member

tianon commented Jun 2, 2015

Good enough for me -- let's get this in; sorry for the delay!

LGTM

@yosifkit
Copy link
Member

yosifkit commented Jun 2, 2015

Can you rebase so that the pretty new tests can run (#73)? Just a git pull --rebase https://github.com/docker-library/mysql.git master and then git push -f.

@ltangvald
Copy link
Collaborator Author

Will do

ltangvald added 3 commits June 3, 2015 08:42
- File with root password in plaintext was readable from database the first time server was run
ltangvald added 4 commits June 3, 2015 08:44
* Removed hardcoded path from my_print_defaults command
* Moved command for setting datadir ownership to before server is started
* Removed unnecessary folder check
* Specify pid-file for 5.5 instead of using hostname
* Change server shutdown check to be more reliable (socket is closed before all resources are released, which could lead to issues)
@ltangvald
Copy link
Collaborator Author

A couple of things to note:

  • Adding --innodb-read-only to the --verbose --help command prevents it from writing to an empty datadir, should this become an issue on Debian as well.
  • We're working on adding functionality that will remove the need for this whole -start-stop-check-if-stopped weirdness, so should be able to improve this in the future :)

@tianon
Copy link
Member

tianon commented Jun 3, 2015

LGTM

(YOU TEASE -- looking forward to something better than our start-stop hackery 👍)

@tianon
Copy link
Member

tianon commented Jun 3, 2015

Also, green tests are 💚.

@yosifkit
Copy link
Member

yosifkit commented Jun 3, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants