To prevent ASAN heap-use-after-poison in the MDEV-16549 part of
./mtr --repeat=6 main.derived
the initialization of Name_resolution_context was cleaned up.
- Added missing information about database of corresponding table for various types of commands
- Update some typos
- Reviewed by: <vicentiu@mariadb.org>
The issue manifests due to a bug in mysql_routine_grant. This was a side
effect of e46eea8660 which fixed the problem of not giving appropriate error
message (ER_NONEXISTING_PROC_GRANT) when a routine grant existed due to role
inheritance.
When granting a routine privilege, it is possible to have a GRANT_NAME
entry already created from an inherited role, but with it's init_privs
set to 0.
In this case we must not create a *new* grant entry, but we must edit
this grant entry to set its init_privs.
Note that this case was already covered by MDEV-29458, however due to a
forgotten "flush privileges;" the actual code path never got hit.
Remove the flush privilege command as it was never intended to be there
in the first place.
There was an issue in updating in-memory role datastructures when
propagating role grants.
The issue is that changing a particular role's privilege (on any
privilege level, global, database, etc.)
was done such that it overwrote the entire set of bits for that
particular level of privileges.
For example:
grant select on *.* to r1 -> sets the access bits to r1 to select,
regardless of what bits were present for role r1 (inherited from any
other roles).
Before this fix, the rights of role r1 were propagated to any roles r1
was granted to, however the propagated rights did *not* include the
complete rights r1 inherited from its own grants.
For example:
grant r2 to r1;
grant select on *.* to r2;
grant insert on *.* to r1; # This command completely disregards the
# select privilege from r2.
In order to correct this, ensure that before rights are propagated
onwards, that the current's role rights have been updated from its
grants.
Additionally, the patch exposed a flaw in the DROP ROLE code.
When deleting a role we removed all its previous grants, but what
remained was the actual links of roles granted to the dropped role.
Having these links present when propagating grants meant that we would
have leftover ACL_xxx entries.
Ensure that the links are removed before propagating grants.
There was a bug in the ACL internal data structures GRANT_TABLE and
GRANT_COLUMN. The semantics are: GRANT_TABLE::init_cols and
GRANT_COLUMN::init_privs represent the bits that correspond to the
privilege bits stored in the physical tables. The other struct members
GRANT_TABLE::cols and GRANT_COLUMN::privs represent the actual access
bits, as they may be modified through role grants.
The error in logic was mixing the two fields and thus we ended up
storing the logical access bits in the physical tables, instead of the
physical (init_xxx) bits.
This caused subsequent DBUG_ASSERT failures when dropping the involved
roles.
This is particularly important for Azure where there is no
MyISAM support in their MariaDB cloud product.
Like mysqldumper does, a view can satisfy the requirement
like a table, without constraints. The views in frm files are
text form and don't have column limits.
Thanks Thomas Casteleyn for the suggestion.
Previously the correct SQL mode for a stored routine or
package was only set before doing the CREATE part, this
worked out for PROCEDUREs and FUNCTIONs, but with ORACLE
mode specific PACKAGEs the DROP also only works in ORACLE
mode.
Moving the setting of the sql_mode a few lines up to happen
right before the DROP statement is writen fixes this.
This happens upon CREATE USER and DROP ROLE.
The underlying problem is that our HASH implementation shuffles elements
around when performing an update or delete. This means that when doing a
scan through the HASH table by index, in search of elements to delete or
update one must restart the scan to make sure nothing is missed if at least
one delete / update happened.
More specifically, what happened in this case:
The hash has 131 element, DROP ROLE removes the element
[119]. Its [119]->next was element [129], so [129] is moved to [119].
Now we need to compact the hash, removing the last element [130]. It
gets one bit off its hash value and becomes element [2]. The existing
element [2] is moved to [129], and old [130] is moved to [2].
We cannot simply move [130] to [129] and make [2]->next=130, it won't
work if [2] is itself in the collision list and doesn't belong in [2].
The handle_grant_struct code assumed that it is safe to continue by only
reexamining the currently modified / deleted element index, but that is
not true.
Missing to delete an element in the hash triggered the assertion in
the test case. DROP ROLE would not clear all necessary role->role or
role->user mappings.
To fix the problem we ensure that the scan is restarted, only if an
element was deleted / updated, similar to how bubble-sort keeps sorting
until it finds no more elements to swap.
