Bug #30432 strange wording / structure used for the SQL SECURITY in views
Submitted: 15 Aug 2007 11:26 Modified: 5 Dec 2007 18:08
Reporter: Roland Bouman Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Server: Documentation Severity:S3 (Non-critical)
Version:5.1, 5.1 OS:Any
Assigned to: Paul DuBois CPU Architecture:Any

[15 Aug 2007 11:26] Roland Bouman
Description:
The structure and wording in the description of the SQL SECURITY and DEFINER clause of the create view statement (f.e. http://dev.mysql.com/doc/refman/5.0/en/create-view.html) is awkward.

The text does not flow very well, and seems to mention facts in the wrong order, immediately talking about corner cases such as creating a view within a procedure. At the same time, the essential information about how privileges on the underlying tables affect the ability to work with the view seem to be lacking, or are maybe described poorly: 

"The SQL SECURITY characteristic determines which MySQL account to use when checking access privileges for the view when the view is executed. The legal characteristic values are DEFINER and INVOKER. These indicate that the view must be executable by the user who defined it or invoked it, respectively. The default SQL SECURITY value is DEFINER."

I don't see how it has anything to do with *creating* the view in particular. I also don't see how a view be *executed*  

How to repeat:
read 
http://dev.mysql.com/doc/refman/5.0/en/create-view.html 
and 
http://dev.mysql.com/doc/refman/5.1/en/create-view.html

Suggested fix:
Suggest to mention the SQL SECURITY clause first, and to explain that this applies to the privilege set that will be in effect when executing a statement that references the view. This should explicitly mention that the privileges that are required to access the underlying tables should be included in that privilege set.

Then the explanation should elaborate on how the privilege set is derived for the DEFINER and INVOKER cases. 

When the DEFINER concept is introduced, the DEFINER clause should be explained. An explicit reference should be made back to SQL Security to explain that this cluase influences what is taken to be the definer. 
Here should be explained that CURRENT_USER maybe written with or without parentheses (instead of the dangling para it is now)

Only after these basic concepts are described should the interaction between views and sp's be described, clearly separated (separate heading maybe?)
[15 Aug 2007 15:32] MySQL Verification Team
Thank you for the bug report.
[5 Dec 2007 18:08] Paul DuBois
Thank you for your bug report. This issue has been addressed in the documentation. The updated documentation will appear on our website shortly, and will be included in the next release of the relevant products.