Skip to content
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

Execute check of MySQL error logfile permissions on Debian 11 only when log_error is defined #477

Merged
merged 1 commit into from
Aug 24, 2021
Merged

Execute check of MySQL error logfile permissions on Debian 11 only when log_error is defined #477

merged 1 commit into from
Aug 24, 2021

Conversation

123quhiwiwk
Copy link
Contributor

This PR fixes checking of log_error file permissions from MariaDB on Debian 11.

If no log_file is defined, then logs goes to systemd and not to the log file. So skip checking permissions of the log_error file if no log_error file is defined on Debian 11.

Fixes #476

@rndmh3ro
Copy link
Member

That's the approach I'd have taken, too.
However Debian 11 is not the only OS that uses systemd/journald. So I'd like to have that condition to work on all OS:

- name: Ensure permissions on mysql-logfile are correct
  file:
    path: '{{ mysql_hardening_log_file }}'
    state: file
    owner: '{{ mysql_hardening_user }}'
    group: '{{ mysql_hardening_group }}'
    mode: '0640'
  when: mysql_settings.settings.log_error == ""

@rndmh3ro
Copy link
Member

LGTM! Can you please sign-off your commits (see https://github.com/dev-sec/ansible-collection-hardening/pull/477/checks?check_run_id=3399247983)?


I just had an even better idea (I think).
Now that we have a variable that defines the path to the log-file, we can take this variable and use it here:

- name: Ensure permissions on mysql-logfile are correct
  file:
    path: '{{ mysql_settings.settings.log_error }}'
    state: file
    owner: '{{ mysql_hardening_user }}'
    group: '{{ mysql_hardening_group }}'
    mode: '0640'
  when: mysql_settings.settings.log_error != ""

I guess this could work.

Then the variable-definition mysql_hardening_log_file can be removed, too. There may be even more things we could dynamically check.
But let's do this in another PR.

…ined

Signed-off-by: 123quhiwiwk <70281681+123quhiwiwk@users.noreply.github.com>
@123quhiwiwk
Copy link
Contributor Author

Yes, mysql_settings.settings.log_error in path seems to work.

What also comes to my mind just now:
I want to activate logging to this error file using the mysql_hardening_options.
So in this case this file will not be checked for permissions.
Would it be possible to check the log_error file after applying the hardening configuration (and restart of db), so that the permissions of this file will also be checked?

@rndmh3ro
Copy link
Member

Would it be possible to check the log_error file after applying the hardening configuration (and restart of db), so that the permissions of this file will also be checked?

In my opinion the configuration of log_error should be done with another role (that installs mysql).
The mysql-hardening role is (somewhat) idempotent so re-running it after changing the log_error-var is possible.

@rndmh3ro rndmh3ro marked this pull request as ready for review August 24, 2021 07:41
@rndmh3ro rndmh3ro merged commit 4671a32 into dev-sec:master Aug 24, 2021
@rndmh3ro
Copy link
Member

Thank you, @123quhiwiwk!

@123quhiwiwk 123quhiwiwk deleted the debian_11_mysql_error_log branch August 24, 2021 13:32
divialth pushed a commit to divialth/ansible-collection-hardening that referenced this pull request Aug 3, 2022
…ined (dev-sec#477)

Signed-off-by: 123quhiwiwk <70281681+123quhiwiwk@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

MariaDB hardening fails, because log_error file is missing [Debian 11]
2 participants