Details
-
Bug
-
Status: In Review (View Workflow)
-
Critical
-
Resolution: Unresolved
-
12.3.3
Description
INSERT ... ON DUPLICATE KEY UPDATE requires SELECT on a column that is only being written. A plain UPDATE assigning the same column with the same privileges works.
This seems to contradict the documented privilege rule for UPDATE (UPDATE documentation):
You need the UPDATE privilege only for columns referenced in an UPDATE that are actually updated. You need only the SELECT privilege for any columns that are read but not modified.
Steps to Reproduce
As an administrative user:
CREATE USER `test_user`; |
CREATE TABLE `test` (`i` INT, `s` VARCHAR(5), PRIMARY KEY(`i`)); |
GRANT INSERT, UPDATE, SELECT(`i`) ON `test` TO `test_user`; |
As test_user:
INSERT INTO `test` (`i`, `s`) VALUES (1, "a"); -- OK |
UPDATE `test` SET `s` = 'b' WHERE `i` = 1; -- OK |
INSERT INTO `test` (`i`, `s`) VALUES (1, "c") ON DUPLICATE KEY UPDATE `s` = "c"; |
-- ERROR 1143 (42000): SELECT command denied to user 'test_user'@'localhost' for column 's' in table 'test' |
Expected: the last statement succeeds and sets `s` = 'c', like the plain UPDATE.
Reproduced on: Community 12.3.3, Enterprise 11.4.10-7, Enterprise 10.6.28-24.
Workaround: grant table-level SELECT.