Skip to content

Privileges not working correctly even after fix of issue #1474 #1502

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

Open
o4ier opened this issue Oct 21, 2022 · 4 comments
Open

Privileges not working correctly even after fix of issue #1474 #1502

o4ier opened this issue Oct 21, 2022 · 4 comments

Comments

@o4ier
Copy link

o4ier commented Oct 21, 2022

Describe the Bug

puppet makes following changes each run:
Notice: /Stage[main]/Mysql::Server::Providers/Mysql_grant[mydba@localhost/.]/privileges: privileges changed ['ALL', 'APPLICATION_PASSWORD_ADMIN', 'AUDIT_ABORT_EXEMPT', 'AUDIT_ADMIN', 'AUTHENTICATION_POLICY_ADMIN', 'BACKUP_ADMIN', 'BINLOG_ADMIN', 'BINLOG_ENCRYPTION_ADMIN', 'CLONE_ADMIN', 'CONNECTION_ADMIN', 'ENCRYPTION_KEY_ADMIN', 'FIREWALL_EXEMPT', 'FLUSH_OPTIMIZER_COSTS', 'FLUSH_STATUS', 'FLUSH_TABLES', 'FLUSH_USER_RESOURCES', 'GROUP_REPLICATION_ADMIN', 'GROUP_REPLICATION_STREAM', 'INNODB_REDO_LOG_ARCHIVE', 'INNODB_REDO_LOG_ENABLE', 'PASSWORDLESS_USER_ADMIN', 'PERSIST_RO_VARIABLES_ADMIN', 'REPLICATION_APPLIER', 'REPLICATION_SLAVE_ADMIN', 'RESOURCE_GROUP_ADMIN', 'RESOURCE_GROUP_USER', 'ROLE_ADMIN', 'SENSITIVE_VARIABLES_OBSERVER', 'SERVICE_CONNECTION_ADMIN', 'SESSION_VARIABLES_ADMIN', 'SET_USER_ID', 'SHOW_ROUTINE', 'SYSTEM_USER', 'SYSTEM_VARIABLES_ADMIN', 'TABLE_ENCRYPTION_ADMIN', 'XA_RECOVER_ADMIN'] to ['ALL'] (corrective)

Expected Behavior

puppet should not change privileges that are already "ALL" to "ALL" in each run.

Steps to Reproduce

Steps to reproduce the behavior:

  1. Setup mysql-server with:
  class { '::mysql::server':
[...]
    users => {
      'mydba@localhost' => {
        ensure        => 'present',
        password_hash => <myhash>,
      },
    grants => {
      'mydba@localhost/*.*' => {
        ensure     => 'present',
        options    => ['GRANT'],
        privileges => ['ALL'],
        table      => '*.*',
        user       => 'mydba@localhost',
      },
[...]
  1. run puppet two+ times

Environment

  • puppetlabs-mysql version v13.0.0
  • mysql-version 8.0
  • puppet agent version 6.28.0
  • Platform RHEL8, RHEL9

Additional Context

I will add a PR soon: #1503
First time, so let me know if I did something wrong

o4ier added a commit to o4ier/puppetlabs-mysql that referenced this issue Oct 21, 2022
@LukasAud
Copy link
Contributor

Hi @o4ier, I noticed you have some suggestions to improve our code. If you could create a PR on our repository (puppetlabs/puppetlabs-mysql), we can officially investigate your proposed changes and run them through our automated testing to make sure they comply with our working standards.

Thanks for taking the time to work on this.

@o4ier
Copy link
Author

o4ier commented Oct 24, 2022

Hello @LukasAud
I reopened the aforementioned PR #1503 with an updated version of my code.
Apparently it fails some conventional tests.
I will come back to you when I have fixed them.

Which is now, local "pdk validate" does not show any warnings

@LukasAud
Copy link
Contributor

That sounds great. Good luck! 👍

@fetzerms
Copy link

I am also seeing the same issue with mariadb-10.3 on RHEL8.

privileges changed ['ALTER', 'ALTER ROUTINE', 'CREATE', 'CREATE ROUTINE', 'CREATE TEMPORARY TABLES', 'CREATE VIEW', 'DELETE', 'DROP', 'EVENT', 'EXECUTE', 'INDEX', 'INSERT', 'LOCK TABLES', 'REFERENCES', 'SELECT', 'SHOW VIEW', 'TRIGGER', 'UPDATE'] to ['ALL'] (corrective)

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

No branches or pull requests

5 participants