* If a db user belonged to a role which had a privilege, the user would
not have the privilege added as the role gave the appearance that the
user already had it. Fixed to always check the privileges specific to
the user.
* Make fewer db queries to determine if privileges need to be changed
and change them (was four for each privilege. Now two for each object
that has a set of privileges changed).
The default value set by the module was a value of None for the
config_file parameter, which propogates into the connect method
call overriding the stated default in the method.
Instead, the default should be set with-in the parameter
specification so the file check is not requested to check None.
Remove `USAGE` from the `VALID_PRIVS` dict for both database and
table because it is not a valid privilege for either (and
breaks the implementation of `has_table_privilege` and
`has_database_privilege`
See http://www.postgresql.org/docs/9.0/static/sql-grant.html
Use `has_table_privileges` and `has_database_privileges`
to test whether a user already has a privilege before
granting it, or whether a user doesn't have a privilege
before revoking it.
For read-only databases, users should not change when no changes
are required.
Don't issue ALTER ROLE when role attribute flags, users password
or expiry time is not changing.
In certain cases (hashed passwords in the DB, but the password
argument is not hashed) passlib.hash is required to avoid
running ALTER ROLE.
Some places ([AWS RDS](https://forums.aws.amazon.com/thread.jspa?threadID=151248)) don't have, or don't allow, access to the `pg_authid` table. The only reason that is necessary is to check for a password change.
This flag is a workaround so passwords can only be set at creation time. It isn't as elegant as changing the password down the line, but it fixes the longstanding issue #297 that prevented this from being useful on AWS RDS.
Docs imply the mysql_variables is used to operate a single variable therefore
- fail before making any db connections if variable is not set
- validate chars for mysql variable name with re.match(^[a-z0-9_]+)
- use "SHOW VARIABLE WHERE Variable_name" instead of LIKE search
- getvariable() returns only the value or None if variable is not found
- the module returns only the found variable value instead of tuple for easier operation eg. as registere variable in tasks
Ports are integer values but the old code was assuming they were
strings. When login_port is put into playbook complex_args as an
integer the code would fail. This update should make the argument
validating make sure we have an integer and then we can send that value
directly to the relevant APIs.
Fixes#818
Use mysql_user module to create, delete users.
Update user password and ensure new password was updated for the correct user.
Assert user has access to multiple databases
Assert user creation, deleting using different user privilege and ensure privilege work correctly.
While the encrypted parameter's documentation clearly states that it needs to
be set, if you are focused on the password parameter's documentation, there's
nothing to draw your attention to the fact that encrypted may also need to be
set.
The mysqldb Ansible module will fail if the state specified is import or dump with a '1045: Access Denied' mysql error for complex passwords.
This is caused by the extra quote around the '--password' argument to mysqldump, as pipes.quotes already quotes the password string.
>>> "--password='%s'" % pipes.quote('simple')
"--password='simple'"
>>> "--password='%s'" % pipes.quote('c0mplexp@ssword!')
"--password=''c0mplexp@ssword!''"
>>> "--password='%s'" % pipes.quote('password with space')
"--password=''password with space''"
* Adds another module utility file which generalizes the
access of urls via the urllib* libraries.
* Adds a new spec generator for common arguments.
* Makes the user-agent string configurable.
Fixes#6211
From the documentation it is not immediately clear that the 'target'
option refers to a location on the remote host. This change emphasizes that.
In addition to .sql files, .bz2 and .gz files are supported for dumps and
restores. This is now documented.
The SET GLOBAL statement requires properly quoting of values. For example, the
following correct queries will fail if quotes are toggled:
mysql> SET GLOBAL innodb_lru_scan_depth = 2000;
mysql> SET GLOBAL master_info_repository = "TABLE";
`mysql_variable` module doesn't quote the value argument, therefore
string values will fail.
# this task will pass, 2000 is passed without quotes
- name: set a numeric value
mysql_variable: variable=innodb_lru_scan_depth value=2000
# this task will fail, TABLE is passed without quotes
- name: set a string value
mysql_variable: variable=master_info_repository value=TABLE
With this patch prepared statements are used. Proper quoting will be
done automatically based on the type of the variables thus an attempt
to convert to int, then to float is done in first place.
Booleans values, ie: ON, OFF, are not specially handled because they
can be quoted. For example, the following queries are correct and
equivalent, they all set _innodb_file_per_table_ to logical _True_:
mysql> SET GLOBAL innodb_file_per_table = "ON";
mysql> SET GLOBAL innodb_file_per_table = ON;
mysql> SET GLOBAL innodb_file_per_table = 1;
Tested in mysql 5.5 and 5.6.
Previously postgresql_user quoted user supplied identifers to create
grant statements that look like this:
GRANT SELECT on "tablename" to "user";
Which only works if the tablename is not in a namespace. If you supply
a namespaced tabelname like "report.revenue" then it creates this
incorrect statement:
GRANT SELECT on "report.revenue" to "user";
Which will not find the "revenue" table in the "report" namespace, but
will rather look for a table named "report.revenue" in the current
(default public) namespace. The correct form is:
GRANT SELECT on "report"."revenue" to "user";
This approach could have the unfortunate effect that code that
previously relied on the other behavior to grant privileges on tables
with periods in their names may now break. PostgreSQL users
typically shouldn't name tables as such, and users can still access the
old behavior and use tablenames with periods in the if they must by
supplying their own quoting.
The password is passed on a command line for dump and import and needs
quoting.
Ideally, this would not be passed on a command line at all - any ideas?
Or at least have a stronger form of quoting so that embedded single
quotes will be escaped.