feat[mysql_info]: add 'users_privs' filter #572
Conversation
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## main #572 +/- ##
==========================================
- Coverage 76.35% 72.01% -4.35%
==========================================
Files 28 15 -13
Lines 2394 2283 -111
Branches 584 580 -4
==========================================
- Hits 1828 1644 -184
- Misses 390 448 +58
- Partials 176 191 +15
Flags with carried forward coverage won't be shown. Click here to find out more.
☔ View full report in Codecov by Sentry. |
|
Ready for review please, if someone has the time, I would really appreciate another pair of eyes. |
|
I'm starting to use this feature (from my fork until next release) and noticed two errors in the keys I used for the output that didn't match what mysql_user is expecting as an input. It's now fixed. I can now say it works perfectly. I just exported 300 accounts and re-create them using mysql_user in check mode. All green :) |
|
Thanks @Andersson007 for your review. Regarding your comment about MySQL 8 being already sorted, I copied the output into my editor. So MySQL must have sorted the privileges for me. But I just discovered an issue with my implementation. Because I sorted the privileges, I get perma-yellow because the order of the privileges don't match the server output anymore. What should I do? Fix my function to not sort the output, or fix mysql_user.changed to always sort privileges before comparison? |
Sorting sounds like a safe solution to me |
|
@laurent-indermuehle i would also suggest implementing testing in a separate PR and then rebasing this one after we merge the testing-related one (i.e. not to keep not tightly related things together) |
|
Not sure why sanity 2.17 complains here, on my computer it works. After a second look, I now see that I didn't sort the privileges! I do it only during comparison with I've changed What do you mean by "testing in a separate PR" @Andersson007? |
I think i saw some test matrix changes here earlier but now i don't:) so just ignore this statement |
|
@Andersson007 ah right, that was the case before I revert my commit were I merge main into that branch. But now MySQL 8.0.31 fails and I don't know why :( |
|
I found what is the weird list of "ALL PRIVILEGES" MySQL 8 is spitting: They are either static (SELECT, INSERT, ...) or dynamic (APPLICATION_PASSWORD_ADMIN, ...). The dynamic privileges are only loaded if the plugin that use them is enabled. More information here: https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#static-dynamic-privileges So that explains why "SHOW GRANTS FOR" was displaying 2 lists. The issue is that I broke everything for 8.0 : When you create a user with all privileges, it got created with only the dynamic privileges. All statics are overwritten by USAGE: GRANT USAGE ON *.* TO `user1`@`%`
GRANT APPLICATION_PASSWORD_ADMIN,[...] ON *.* TO `user1`@`%`
-- Instead of
GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, [...] ON *.* TO `user1`@`%`
GRANT APPLICATION_PASSWORD_ADMIN,[...] ON *.* TO `user1`@`%`We have 2 functions in This is so wrong... |
|
@Andersson007 no need to search anymore. I just found the issue. Thanks anyway. The tests use a loop. So the second iteration uses user_mod(). And also, I used to disable many tests to speed up my feedback loop, but this time it masked many regressions I introduced. Slow tests makes me do stupid things -_-' |
This debug output this:
[
{'Grants for root@localhost': \"GRANT ALL PRIVILEGES ON *.* TO 'root'@'localhost' WITH GRANT OPTION\"},
{'Grants for root@localhost': \"GRANT PROXY ON ''@'' TO 'root'@'localhost' WITH GRANT OPTION\"}
],
[
{'Grants for mysql.session@localhost': \"GRANT SUPER ON *.* TO 'mysql.session'@'localhost'\"},
{'Grants for mysql.session@localhost': \"GRANT SELECT ON `performance_schema`.* TO 'mysql.session'@'localhost'\"},
{'Grants for mysql.session@localhost': \"GRANT SELECT ON `mysql`.`user` TO 'mysql.session'@'localhost'\"}
],
[
{'Grants for mysql.sys@localhost': \"GRANT USAGE ON *.* TO 'mysql.sys'@'localhost'\"},
{'Grants for mysql.sys@localhost': \"GRANT TRIGGER ON `sys`.* TO 'mysql.sys'@'localhost'\"},
{'Grants for mysql.sys@localhost': \"GRANT SELECT ON `sys`.`sys_config` TO 'mysql.sys'@'localhost'\"}
],
[
{'Grants for root@%': \"GRANT ALL PRIVILEGES ON *.* TO 'root'@'%' WITH GRANT OPTION\"}
]
I think something is wrong in the lambda and when grants art on ''@''.
I was getting KeyError 0
Even if you use print_identified_with_as_hex to prevent the password to contains binary characters. I think this is because PyMySQL and mysqlclient wrap the password in quote. We could try to convert to another python connector, like mysql-connector-python.
Co-authored-by: Andrew Klychkov <[email protected]>
Co-authored-by: Andrew Klychkov <[email protected]>
Co-authored-by: Andrew Klychkov <[email protected]>
This reverts commit 77593b7. I imported PR569 to be able to test on my fork, but to avoid polluting this patch I now revert those commit.
We summarize ALL for mysql_info, but mysql_user needs to compare actual privileges with the ones provided by ansible.
This was introduced in ansible-collections#189. To my knowledge, there is no difference between MySQL and MariaDB regarding roles or when you call a user by its name alone. Both works if the host it '%'. Same for roles.
This reverts commit de1cbae. Mariadb write the 'host' of a role as '' while mysql write '%'.
laurent-indermuehle
force-pushed
the
lie_mysql_info_users_privs
branch
from
de1cbae to
2e2780b
Compare
|
This PR started before others PR, merged since, required for this one. So, for the explanation: The issue was that |
SUMMARY
Add filter
users_privsto themysql_infomodule.ISSUE TYPE
COMPONENT NAME
mysql_infoADDITIONAL INFORMATION
This filter returns information about users accounts. The output can be used as an input of the mysql_user plugin. Useful when migrating accounts to a new server or to create an inventory.
It doesn't return informations about
password_optionandlock_optionbut since themysql_usermodule doesn't support them, I don't bother implemented them yet.Doesn't support
sha256_passwordandcaching_sha2_passwordauthentication plugins. Even if you use print_identified_with_as_hex to convert the password into a hash. I think this is because PyMySQL andmysqlclient wrap the password in quote:
CREATE USER... IDENTIFIED AS '0x1234'instead ofCREATE USER... IDENTIFIED AS 0x1234. We could try to convert to another python connector, like mysql-connector-python. But this is way too much work for me who only work on MariaDB withmysql_native_password.