| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |\ |
|
| | |
| |
| |
| |
| |
| | |
- Proceed with commit fafb35ee517f309d9e507f6e3908caca5d8cd257
Reviewed by: serg@mariadb.com
|
| |\ \
| |/ |
|
| | | |
|
| |\ \
| |/ |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
Classes that handle privilege tables (like Tables_priv_table)
could read some columns conditionally but they expect a certain
minimal number of colunms always to exist.
Add a check for a minimal required number of columns in privilege tables,
don't use a table that has fewer columns than required.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
check_grant_all_columns
With RETURNING it can happen that the user has some privileges on
the table (namely, DELETE), but later needs different privileges
on individual columns (namely, SELECT).
Do the same as in check_grant_column() - ER_COLUMNACCESS_DENIED_ERROR,
not an assert.
|
| |\ \
| |/ |
|
| | |
| |
| |
| | |
Quotes added to output.
|
| | |
| |
| |
| | |
followup for 0a43df4fbc7
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
fixes
MDEV-14732 mysql.db privileges evaluated on order of grants rather than hierarchically
MDEV-8269 Correct fix for Bug #20181776 :- ACCESS CONTROL DOESN'T MATCH MOST SPECIFIC HOST WHEN IT CONTAINS WILDCARD
reimplement the old ad hoc get_sort() function to use a wildcard
pattern ordering logic that works correctly in may be all practical cases.
get_sort() is renamed to catch merge errors at compilation time.
moved to a separate included file, because of a long comment.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
non-existing plugin
Revert the side effect of 7c40996cc866.
Do not convert password hash to its binary representation when a user
entry is loaded. Do it lazily on the first authenticatation attempt.
As a collateral - force all authentication plugins to follow the
protocol and read_packet at least once before accessing info->username
(username is not available before first client handshake packet is read).
Fix PAM and GSSAPI plugins to behave.
|
| |\ \
| |/ |
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
Implement User_table_json.
Fix scripts to use mysql.global_priv.
Fix tests.
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Support SET PASSWORD for authentication plugins.
Authentication plugin API is extended with two optional methods:
* hash_password() is used to compute a password hash (or digest)
from the plain-text password. This digest will be stored in mysql.user
table
* preprocess_hash() is used to convert this digest into some memory
representation that can be later used to authenticate a user.
Build-in plugins convert the hash from hexadecimal or base64 to binary,
to avoid doing it on every authentication attempt.
Note a change in behavior: when loading privileges (on startup or on
FLUSH PRIVILEGES) an account with an unknown plugin was loaded with a
warning (e.g. "Plugin 'foo' is not loaded"). But such an account could
not be used for authentication until the plugin is installed. Now an
account like that will not be loaded at all (with a warning, still).
Indeed, without plugin's preprocess_hash() method the server cannot know
how to load an account. Thus, if a new authentication plugin is
installed run-time, one might need FLUSH PRIVILEGES to activate all
existing accounts that were using this new plugin.
|
| |
|
