Bug #74868 STRICT mode reveals underlying privilege error

• Submitted: 14 Nov 2014 14:38
• Modified: 14 Feb 2015 17:05
• Reporter: Roy Lyseng
• Status: Closed
• Category: MySQL Server: Errors
• Severity: S3 (Non-critical)
• Version: 5.7.5
• OS: Any
• CPU Architecture: Any

[14 Nov 2014 14:38] Roy Lyseng

Description:
When we have a privilege error in the underlying table of a view,
an error processor is supposed to suppress this error and instead
supply a more general error, so that we do not reveal any details
about the contents of a view.
However, with STRICT mode set, this suppression no longer occurs.

The problem seems to be that TABLE_LIST::hide_view_error() exits
immediately when an internal error handler is set up.

How to repeat:
CREATE DATABASE test1;
CREATE USER user1@localhost;

CREATE TABLE test1.t1
 (cn CHAR(1), cs CHAR(1), ci CHAR(1), cu CHAR(1), cus CHAR(1));
GRANT SELECT(cs,cus) ON test1.t1 TO user1@localhost;
GRANT INSERT(ci) ON test1.t1 TO user1@localhost;
GRANT UPDATE(cu,cus) ON test1.t1 TO user1@localhost;

CREATE SQL SECURITY INVOKER VIEW test1.v1_all AS
SELECT * FROM test1.t1;
GRANT SELECT,INSERT,UPDATE,DELETE ON test1.v1_all TO user1@localhost;

Connect as user user1 and perform:

set sql_mode='strict_trans_tables';

UPDATE test1.v1_all SET cn='x';

This returns ER_COLUMNACCESS_DENIED_ERROR (1143)

set sql_mode='';

UPDATE test1.v1_all SET cn='x';

This returns ER_VIEW_INVALID (1356).

The latter should be returned in strict mode too.

[14 Feb 2015 17:05] Paul DuBois

Noted in 5.7.6 changelog.

For a privilege error on a table underlying a view, a more general
error should be supplied for attempts to access the view, so as not
to provide information about the view contents. This did not happen
in strict SQL mode.