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.
A query with a group by and having clauses could return a wrong
result set if the having condition contained a constant conjunct
evaluated to FALSE.
It happened because the pushdown condition for table with
grouping columns lost its constant conjuncts.
Pushdown conditions are always built by the function make_cond_for_table
that ignores constant conjuncts. This is apparently not correct when
constant false conjuncts are present.
which was fixed by earlier changesets; LOAD INDEX is not allowed in functions.
Also testing CACHE INDEX, while OPTIMIZE and CHECK were covered by existing tests already.
post-review change - use pointer instead of copy on the stack.
WL#1034 (Internal CRON)
This patch adds INFORMATION_SCHEMA.EVENTS table with the following format:
EVENT_CATALOG - MYSQL_TYPE_STRING (Always NULL)
EVENT_SCHEMA - MYSQL_TYPE_STRING (the database)
EVENT_NAME - MYSQL_TYPE_STRING (the name)
DEFINER - MYSQL_TYPE_STRING (user@host)
EVENT_BODY - MYSQL_TYPE_STRING (the body from mysql.event)
EVENT_TYPE - MYSQL_TYPE_STRING ("ONE TIME" | "RECURRING")
EXECUTE_AT - MYSQL_TYPE_TIMESTAMP (set for "ONE TIME" otherwise NULL)
INTERVAL_VALUE - MYSQL_TYPE_LONG (set for RECURRING otherwise NULL)
INTERVAL_FIELD - MYSQL_TYPE_STRING (set for RECURRING otherwise NULL)
SQL_MODE - MYSQL_TYPE_STRING (for now NULL)
STARTS - MYSQL_TYPE_TIMESTAMP (starts from mysql.event)
ENDS - MYSQL_TYPE_TIMESTAMP (ends from mysql.event)
STATUS - MYSQL_TYPE_STRING (ENABLED | DISABLED)
ON_COMPLETION - MYSQL_TYPE_STRING (NOT PRESERVE | PRESERVE)
CREATED - MYSQL_TYPE_TIMESTAMP
LAST_ALTERED - MYSQL_TYPE_TIMESTAMP
LAST_EXECUTED - MYSQL_TYPE_TIMESTAMP
EVENT_COMMENT - MYSQL_TYPE_STRING
SQL_MODE is NULL for now, because the value is still not stored in mysql.event .
Support will be added as a fix for another bug.
This patch also adds SHOW [FULL] EVENTS [FROM db] [LIKE pattern]
1. SHOW EVENTS shows always only the events on the same user,
because the PK of mysql.event is (definer, db, name) several
users may have event with the same name -> no information disclosure.
2. SHOW FULL EVENTS - shows the events (in the current db as SHOW EVENTS)
of all users. The user has to have PROCESS privilege, if not then
SHOW FULL EVENTS behave like SHOW EVENTS.
3. If [FROM db] is specified then this db is considered.
4. Event names can be filtered with LIKE pattern.
SHOW EVENTS returns table with the following columns, which are subset of
the data which is returned by SELECT * FROM I_S.EVENTS
Db
Name
Definer
Type
Execute at
Interval value
Interval field
Starts
Ends
Status
