Re: bk commit into 5.0 tree (dlenev:1.2001) BUG#13402

[SGreen]

Does this change mean that view security is going to be evaluated in the 
contexts of the people who created them or in the context of the users 
attempting to use them?

How would this scenario work with your change?  Here is the setup:

Tables t1, t2, and t3 exist. 

UserA has full rights to t1,t2, and t3.

UserB has SELECT rights to t1 and t2 but not t3.

UserA defines a view that uses columns from both t1 and t3: TestView1

Test 1:

An administrator tries to grant SELECT rights to TestView 1 to UserB. What 
happens? Why?

Test 2: 

(assuming the GRANT from event 1 succeeds) UserB tries to use TestView1 in 
a SELECT query. What happens? Why?  Does the query completely fail? Will 
it fail only if UserB references a column that originates from t3? Will 
UserB be able to see the information from t3 exposed through TestView1? 

<<end scenario>>

Some other questions I have about view security:

>>Why is it important to know who made the view when it comes time to 
evaluate the view?

>>What context does the owner's/creator's information provide to the task 
of rendering the view to a user? 

>> When are user-level permissions determined when accessing a view? Do 
the user's permissions start and stop at the VIEW level or are they also 
inherited from the underlying tables (do a view's permission definitions 
override the definitions for the underlying tables)? (Note: defining a 
view to expose just part of a table that a user normally couldn't access 
is currently allowed in several other RDBMS's. I will review SQL2003 later 
tonight to see what the spec allows but I don't have the time right now. 
Sorry! )

>> Will views have column-level security, like tables? 

Thanks!!

Shawn Green
Database Administrator
Unimin Corporation - Spruce Pine

dlenev@stripped wrote on 09/23/2005 01:28:55 PM:

> Below is the list of changes that have just been committed into a local
> 5.0 repository of dlenev. When dlenev does a push these changes will
> be propagated to the main repository and, within 24 hours after the
> push, to the public repository.
> For information on how to access the public repository
> see http://dev.mysql.com/doc/mysql/en/installing-source-tree.html
> 
> ChangeSet
>   1.2001 05/09/23 21:28:47 dlenev@stripped +1 -0
>   Fix for yet another compilation failure on Windows which was 
> introduced during
>   work on WL#2787 "Add view definer/owner to the view definition (.
> frm) to check
>   privileges on used tables and stored routines when using a VIEW."
>   (aka bug #13402 "Windows VS 2003 Compiler error")
> 
>   sql/mysqld.cc
>     1.503 05/09/23 21:28:42 dlenev@stripped +2 -2
>     handle_connections_namedpipes():
>       THD::host member has moved to the Security_context class.
>       New THD::security_ctx member points to active security context.
> 
> # This is a BitKeeper patch.  What follows are the unified diffs for the
> # set of deltas contained in the patch.  The rest of the patch, the part
> # that BitKeeper cares about, is below these diffs.
> # User:   dlenev
> # Host:   brandersnatch.localdomain
> # Root:   /home/dlenev/src/mysql-5.0-bg13407
> 
> --- 1.502/sql/mysqld.cc   2005-09-23 17:09:59 +04:00
> +++ 1.503/sql/mysqld.cc   2005-09-23 21:28:42 +04:00
> @@ -4016,8 +4016,8 @@
>        delete thd;
>        continue;
>      }
> -    /* host name is unknown */
> -    thd->host = my_strdup(my_localhost,MYF(0)); /* Host is unknown */
> +    /* Host is unknown */
> +    thd->security_ctx->host= my_strdup(my_localhost, MYF(0));
>      create_new_thread(thd);
>    }
> 
> 
> -- 
> MySQL Internals Mailing List
> For list archives: http://lists.mysql.com/internals
> To unsubscribe: http://lists.mysql.com/internals?unsub=1
>