Bug #24404 strange bug with view+permission+prepared statement
Submitted: 17 Nov 2006 18:54 Modified: 1 Feb 2007 1:19
Reporter: Matthias Leich Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Server: Prepared statements Severity:S1 (Critical)
Version:5.0 OS:
Assigned to: Tomash Brechko
Tags: rt_q1_2007

[17 Nov 2006 18:54] Matthias Leich
Description:
# Test derived from the NIST tests
# dml132  TEST:0525 FIPS sizing
Snip of my protocol with heavy simplified testcase:
user mysqltest2 runs
CREATE TABLE BASE_WCOV (C1 INT);
SELECT COUNT(*) FROM
mysqltest1.VSTAFF3 T09, BASE_WCOV T10 ;
COUNT(*)
0
prepare stmt1 from "SELECT COUNT(*) FROM
mysqltest1.VSTAFF3 T09, BASE_WCOV T10" ;
execute stmt1;
ERROR 42000: SELECT command denied to user 'mysqltest1'@'localhost' for table 'BASE_WCOV'
The curious things:
1. The non prepared statement runs, the prepared statement gets an error
2. mysqltest2 is the current user and owns the table BASE_WCOV
3. The error message says command denied to user 'mysqltest1'@'localhost'
   though the current user is mysqltest2 !

My environment:
- PC Intel Pentium M (x86-32Bit) with Linux(SuSE 10.1)
- MySQL compiled from source
     mysql-5.0 last ChangeSet@1.1616.2839.8, 2006-11-15
     mysql-5.1 last ChangeSet@1.2365, 2006-11-15
                shows the same bug
     BUILD/compile-pentium-debug-max

How to repeat:
Please use the attached file:
cd <top directory of release>/mysql-test
mv n1.test t
# Produce a Dummy result file
echo "Dummy" > r/n1.result
./mysql-test-run --skip-ndb n1
Inspect r/n1.reject
[17 Nov 2006 18:57] Matthias Leich
test script

Attachment: n1.test (application/octet-stream, text), 5.60 KiB.

[10 Jan 2007 15:21] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/17852

ChangeSet@1.2320, 2007-01-10 18:15:22+03:00, kroki@moonlight.home +3 -0
  Bug#24404: strange bug with view+permission+prepared statement.
  
  The problem was that if a prepared statement accessed a view, the
  access to the tables listed in the query after that view was done in
  the security context of the view.
  
  The bug was in the assigning of the security context to the tables
  belonging to a view: we traversed the list of all query tables
  instead.  It didn't show up in the normal (non-prepared) statements
  because of the different order of the steps of checking privileges
  and descending into a view for normal and prepared statements.
  
  The solution is to traverse the right list (use next_local pointer
  instead of next_global).
[16 Jan 2007 14:07] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/18188

ChangeSet@1.2320, 2007-01-16 17:01:15+03:00, kroki@moonlight.home +3 -0
  Bug#24404: strange bug with view+permission+prepared statement.
  
  The problem was that if a prepared statement accessed a view, the
  access to the tables listed in the query after that view was done in
  the security context of the view.
  
  The bug was in the assigning of the security context to the tables
  belonging to a view: we traversed the list of all query tables
  instead.  It didn't show up in the normal (non-prepared) statements
  because of the different order of the steps of checking privileges
  and descending into a view for normal and prepared statements.
  
  The solution is to traverse the list and stop after view_tables_tail
  is processed.
[16 Jan 2007 17:18] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/18202

ChangeSet@1.2320, 2007-01-16 20:11:59+03:00, kroki@moonlight.home +3 -0
  Bug#24404: strange bug with view+permission+prepared statement.
  
  The problem was that if a prepared statement accessed a view, the
  access to the tables listed in the query after that view was done in
  the security context of the view.
  
  The bug was in the assigning of the security context to the tables
  belonging to a view: we traversed the list of all query tables
  instead.  It didn't show up in the normal (non-prepared) statements
  because of the different order of the steps of checking privileges
  and descending into a view for normal and prepared statements.
  
  The solution is to traverse the list and stop after view_tables_tail
  is processed.
[18 Jan 2007 9:54] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/18317

ChangeSet@1.2320, 2007-01-18 12:48:17+03:00, kroki@moonlight.home +3 -0
  Bug#24404: strange bug with view+permission+prepared statement.
  
  The problem was that if a prepared statement accessed a view, the
  access to the tables listed in the query after that view was done in
  the security context of the view.
  
  The bug was in the assigning of the security context to the tables
  belonging to a view: we traversed the list of all query tables
  instead.  It didn't show up in the normal (non-prepared) statements
  because of the different order of the steps of checking privileges
  and descending into a view for normal and prepared statements.
  
  The solution is to traverse the list and stop once the last table
  belonging to the view was processed.
[18 Jan 2007 14:44] Tomash Brechko
Queued to 5.0-runtime and 5.1-runtime.
[1 Feb 2007 1:19] Jon Stephens
Thank you for your bug report. This issue has been committed to our source repository of that product and will be incorporated into the next release.

If necessary, you can access the source repository and build the latest available version, including the bug fix. More information about accessing the source trees is available at

    http://dev.mysql.com/doc/en/installing-source.html

Documented bugfix in 5.0.36 and 5.1.16 changelogs.