--disable_abort_on_error

--enable_connect_log

CREATE DATABASE privtest_db;

USE privtest_db;

CREATE TABLE privtest_db.t1 (a INT, b INT);

CREATE TABLE privtest_db.t2 (a INT);

INSERT INTO privtest_db.t1 VALUES (1,1), (2,2), (3,3);

GRANT ALL ON privtest_db.t2 TO 'privtest'@'localhost';

GRANT DELETE ON privtest_db.t1 TO 'privtest'@'localhost';

connect(con1,localhost,privtest,,);

USE privtest_db;

DELETE t1 FROM t1, t2;

--connection default

GRANT SELECT(b) ON privtest_db.t1 TO 'privtest'@'localhost';

--connection con1

DELETE t1 FROM t1, t2;

We have full access to the table we join with (to make things more obvious), and DELETE privilege on the table we delete from. The tables are joined unconditionally.

The DELETE fails due to the lack of SELECT privilege on t1:

SELECT command denied to user 'privtest'@'localhost' for table 't1'

The theory that SELECT is needed for the join does not survive the next test: we add a SELECT privilege on one of two columns in t1 and run the same DELETE again. Now it succeeds.

Since the JOIN is unconditional, it should either require no SELECT privilege on the table we delete from, or full SELECT on all columns. One column-SELECT should not make any difference.