mysql_service and mysql_config use different users

[geleman]

Cookbook version

[Version of the cookbook where you are encountering the issue] all

Chef-client version

[Version of chef-client in your environment] 12.11.18

Platform Details

[Operating system distribution and release version. Cloud provider if running in the cloud] centos 7

Scenario:

[What you are trying to achieve and you can't?]

Steps to Reproduce:

[If you are filing an issue what are the things we need to do in order to repro your problem? How are you using this cookbook or any resources it includes?] The mysql_service resource and mysql_config resource should be tied to the same user/group.

Currently you can set the mysql_service user with an attribute/parameter run_group and run_user.

If you spin up centos 7 version using any version of this cookbook and create a user not named mysql you will get a restart error because you default the user in the mysql_config to user mysql but that doesn't change if you use a different user for the mysql_service resource.

Once you run the cookbook you will see the conf.d is owned by the user you selected for mysql_service but the template you apply for new options is owned by mysql with 640 permissions and will fail the restart.

https://github.com/chef-cookbooks/mysql/blob/master/libraries/mysql_config.rb#L39-L48

Expected Result:

[What are you expecting to happen as the consequence of above reproduction steps?] successful install restart

Actual Result:

[What actually happens after the reproduction steps? Include the error output or a link to a gist if possible.] restart failure

[iennae]

This is somewhat intentional to help folks be able to use different users for different databases on the same server. Both default to using user/group mysql unless you explicitly set them. I'm a little worried that changing this will tie these two resources in a ways that make it really complex to maintain this feature. Thoughts on how to resolve this without impacting this particular feature?

[geleman]

For one you shouldn't be running multiple instances on a single server, that is very bad practice. Also I'm getting failures now if I change the mysql_service user to something other than default because the default user for mysql_config is mysql and it has 0600 permissions on the my.cnf file which doesn't allow me to read the file if i'm not the user/user group. This failure is happening on Centos 7 but not Centos 6 for some reason but it exposes the problem nonetheless.

Also considering the recent issue I raised about the move to 0700 from 0600 on the config file because of remote execution also exposes the fact that people generally want to take the easy way around. Databases protect data and should not be easy to configure out the box. This is why you see breaches all the time and it's because of this thought process.

I don't see how this make this cookbook complex to maintain when you will have a single user own the instance and the config file. To me this is actually a easier way to maintain this cookbook because you don't have to track multiple users and who owns what. You can still run multiple instances with the same user using different config files. If a user wants to use different users you should leave it to them to do wrappers that address that where they create users and change ownership after the fact to that user. I have actually done this by creating the mysql user before your mysql cookbook runs because i set ownerships before the install so that i can move my data/logs to any locations on any directory structure I want.

One possible solution might be linking the user groups together but I still think this is an issue because you still can't use 0600.

[iennae]

@geleman I understand that you have different preferences for how the system works, but the feature of multiple instances on a single server with this cookbook hasn't changed recently.

The move from 0700 permissions sounds like you've filed in a separate issue so I'm not going to address it here.

If you have a proposal about how to maintain the current functionality and do what you are suggesting with regards to tying the two resources together that would be helpful. Just saying something is bad doesn't solve the problem if folks are using that feature and have come to expect it to be available.

What I don't understand is why you don't set up it up so that the users/group is the same in your wrapper cookbook when calling the resources. Is something blocking that from happening?

Thanks for your clarification.

[geleman]

It's not about me having a preference rather than following a best practice as set forth by mysql. This isn't a witch hunt but I am aggressive in asserting my point of trying to help the community get to a place that implements good practice that benefits everybody and protects data.

The 0700 permission has already been addressed and was fixed in 8.1.1. Also I have suggested a fix and that is linking the user and groups or just the groups. Again I understand this might affect people but so did switching to LWRP. You can always pull the older version if you don't want to change.

Also the cookbook I discovered this in is not my cookbook and I moved the cookbook back to the default mysql user so it would work again in Centos 7. The problem still lies in the fact that you have the my.cnf file set to 0600 which it should be but being owned by mysql because of the mysql_config resource and if you name the mysql_service resource run_user and run_group something different you get a failure to restart due to permission issues.

[iennae]

@geleman I haven't said this is a witch hunt. Can you point to what you are saying is a best practice from mysql here? My concern is about breaking changes to folks who are using features in ways that I can't predict.

[cheeseplus]

Closing this one due to lack of response and the fact the crux of the problem is already well covered in #486. We've provided how it should be used given current implementation but also don't trying to minimize/collapse the number of threads that are effectively covering the same root issue.

[lock[bot]]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.