| 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: | |
| Category: | MySQL Server: Prepared statements | Severity: | S1 (Critical) |
| Version: | 5.0 | OS: | |
| Assigned to: | Tomash Brechko | CPU Architecture: | Any |
| Tags: | rt_q1_2007 | ||
[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.
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