Implement table-level TRIGGER privilege to control access to triggers.
Before this path global SUPER privilege was used for this purpose, that
was the big security problem.
In details, before this patch SUPER privilege was required:
- for the user at CREATE TRIGGER time to create a new trigger;
- for the user at DROP TRIGGER time to drop the existing trigger;
- for the definer at trigger activation time to execute the trigger (if the
definer loses SUPER privilege, all its triggers become unavailable);
This patch changes the behaviour in the following way:
- TRIGGER privilege on the subject table for trigger is required:
- for the user at CREATE TRIGGER time to create a new trigger;
- for the user at DROP TRIGGER time to drop the existing trigger;
- for the definer at trigger activation time to execute the trigger
(if the definer loses TRIGGER privilege on the subject table, all its
triggers on this table become unavailable).
- SUPER privilege is still required:
- for the user at CREATE TRIGGER time to explicitly set the trigger
definer to the user other than CURRENT_USER().
When the server works with database of the previous version (w/o TRIGGER
privilege), or if the database is being upgraded from the previous versions,
TRIGGER privilege is granted to whose users, who have CREATE privilege.
Added search for 'my_print_defaults' when running from source tree on Windows
trigger-grant.test, trigger-compat.test:
Removed --text from grep, not portable
