MySQL Forums
Forum List  »  General

Confused about view privileges
Posted by: Per Holm
Date: March 16, 2006 01:57AM

I am totally confused about views and view privileges (see also the thread http://forums.mysql.com/read.php?100,71700).

The manual says this in section 19.2:

"At view execution time, privileges for objects accessed by the view are checked against the privileges held by the view creator or invoker, depending on whether the SQL SECURITY characteristic is DEFINER or INVOKER, respectively."

This I take to mean that if a view is defined as "create security INVOKER view v as select * from t", and a user only has the SELECT privilege on t, he shouldn't be able to update the base table t in any way, neither directly nor via the view. This should be regardless of what privileges the user has on the view v.

But this he can do -- if he has delete and update privileges on v he can "delete from v;" and "update v set ...", and the base table t is changed. It seems that deletions and updates don't check "privileges for objects accessed by the view" at all, only privileges on the view.

This seems unreasonable to me, and I thought is was an obvious bug. But then I read in the article http://dev.mysql.com/tech-resources/articles/mysql-views.pdf, page 15:

"Special rule: If you have a privilege to perform an operation on a view, you don't need the same privilege on the underlying tables. That is, if you have the UPDATE privilege on view v, which is based on table t, you can update v -- assuming that v is updatable. There is no requirement that you have the UPDATE privilege on t as well."

Is this really the intended behaviour? If it is, what is the motivation?

I would be very grateful if someone could clarify this!

Options: ReplyQuote


Subject
Written By
Posted
Confused about view privileges
March 16, 2006 01:57AM


Sorry, you can't reply to this topic. It has been closed.

Content reproduced on this site is the property of the respective copyright holders. It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.