db-derby-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From fuzzylo...@apache.org
Subject svn commit: r440851 - in /db/derby/docs/trunk/src: devguide/cdevcsecuregrantrevokeaccess.dita devguide/derbydev.ditamap ref/refderby.ditamap ref/rrefsistabs12813.dita ref/rrefsqljrevoke.dita
Date Wed, 06 Sep 2006 19:51:56 GMT
Author: fuzzylogic
Date: Wed Sep  6 12:51:55 2006
New Revision: 440851

URL: http://svn.apache.org/viewvc?view=rev&rev=440851
Log:
DERBY-1646: Documentation to address Grant/Revoke Authorization for views/triggers/constraints/routines.

Committed for Laura Stewart <scotsmatrix@gmail.com>

Modified:
    db/derby/docs/trunk/src/devguide/cdevcsecuregrantrevokeaccess.dita
    db/derby/docs/trunk/src/devguide/derbydev.ditamap
    db/derby/docs/trunk/src/ref/refderby.ditamap
    db/derby/docs/trunk/src/ref/rrefsistabs12813.dita
    db/derby/docs/trunk/src/ref/rrefsqljrevoke.dita

Modified: db/derby/docs/trunk/src/devguide/cdevcsecuregrantrevokeaccess.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/devguide/cdevcsecuregrantrevokeaccess.dita?view=diff&rev=440851&r1=440850&r2=440851
==============================================================================
--- db/derby/docs/trunk/src/devguide/cdevcsecuregrantrevokeaccess.dita (original)
+++ db/derby/docs/trunk/src/devguide/cdevcsecuregrantrevokeaccess.dita Wed Sep  6 12:51:55
2006
@@ -1,4 +1,5 @@
 <?xml version="1.0" encoding="utf-8"?>
+ 
 <!DOCTYPE concept PUBLIC "-//OASIS//DTD DITA Concept//EN"
  "concept.dtd">
 <!-- 
@@ -65,9 +66,9 @@
 and revoked to PUBLIC and to individual users are independent. For example,
 a SELECT privilege on table <codeph>t</codeph> is granted to both PUBLIC and
 to the user <codeph>harry</codeph>. The SELECT privilege is later revoked
-from <codeph>harry</codeph>, but Harry has access to table <codeph>t</codeph>
through
-the PUBLIC privilege.</p><note othertype="Exception" type="other">When you
-create a view, trigger, or constraint, <ph conref="devconrefs.dita#prod/productshortname"></ph>
first
+from user <codeph>harry</codeph>, but user <codeph>harry</codeph>
has access
+to table <codeph>t</codeph> through the PUBLIC privilege.</p><note othertype="Exception"
+type="other">When you create a view, trigger, or constraint, <ph conref="devconrefs.dita#prod/productshortname"></ph>
first
 checks to determine if you have the required privileges at the user-level.
 If you have the user-level privileges, the object is created and is dependent
 on that user-level privilege. If you do not have the required privileges at
@@ -95,37 +96,42 @@
 SELECT privileges to PUBLIC. User <codeph>harry</codeph> creates view <codeph>v1</codeph>
with
 the statement SELECT * from <codeph>anita.t1</codeph>. The view depends on
 the PUBLIC level privilege that user <codeph>harry</codeph> has on <codeph>t1</codeph>
since
-user <codeph>harry</codeph> does not have user-level privileges on table <codeph>t1</codeph>.
-Subsequently, user <codeph>anita</codeph> revokes SELECT privileges from PUBLIC
-on table <codeph>t1</codeph>. As a result, the view <codeph>harry.v1</codeph>
is
-dropped. </dd>
+user <codeph>harry</codeph> does not have user-level privileges on table <codeph>t1</codeph>
when
+he creates the view <codeph>harry.v1</codeph>. Subsequently, user <codeph>anita</codeph>
grants
+SELECT privileges to user <codeph>harry</codeph> on table <codeph>anita.t1</codeph>.
+The view <codeph>harry.v1</codeph> continues to depend on  PUBLIC level privilege
+that user <codeph>harry</codeph> has on <codeph>t1</codeph>. When
user <codeph>anita</codeph> revokes
+SELECT privileges from PUBLIC on table <codeph>t1</codeph>, the view <codeph>harry.v1</codeph>
is
+dropped.</dd>
 </dlentry></dl></note></section>
 <section><title>Permissions on views, triggers, and constraints</title><p>Views,
 triggers, and constraints operate with the permissions of the owner of the
-view, trigger, or constraint. The For example, Anita wants to create a view
-using the following statement:<codeblock>CREATE VIEW s.v(vc1,vc2,vc3)
+view, trigger, or constraint. For example, user <codeph>anita</codeph> wants
+to create a view using the following statement:<codeblock>CREATE VIEW s.v(vc1,vc2,vc3)
 	AS SELECT t1.c1,t1.c2,f(t1.c3)
   FROM t1 JOIN t2 ON t1.c1 = t2.c1 
-	WHERE t2.c2 = 5</codeblock>Anita needs the following permissions to create
-the view:<ul>
+	WHERE t2.c2 = 5</codeblock>User <codeph>anita</codeph> needs the following
+permissions to create the view:<ul>
 <li>Ownership of the schema <codeph>s</codeph>, so that she can create
something
 in the schema</li>
 <li>Ownership of the table <codeph>t1</codeph>, so that she can allow others
 to see columns in the table</li>
-<li>SELECT permission on <codeph>t2.c1</codeph> and <codeph>t2.c2</codeph></li>
-<li>EXECUTE permission on <codeph>f</codeph></li>
-</ul>When the view is created, only Anita has SELECT permission on it. Anita
-can grant SELECT permission on any or all of the columns of view <codeph>s.v</codeph>
to
-anyone, even to users who do not have SELECT permission on <codeph>t1</codeph>
or <codeph>t2</codeph>,
-or EXECUTE permission on <codeph>f</codeph>. Anita grants SELECT permission
-on view <codeph>s.v</codeph> to Harry. When Harry issues a SELECT statement
-on the view <codeph>s.v</codeph>, <ph conref="devconrefs.dita#prod/productshortname"></ph>
checks
-to determine if Harry has SELECT permission on view<codeph>s.v</codeph>. <ph
+<li>SELECT permission on column <codeph>t2.c1</codeph> and column <codeph>t2.c2</codeph></li>
+<li>EXECUTE permission on function <codeph>f</codeph></li>
+</ul>When the view is created, only user <codeph>anita</codeph> has SELECT
+permission on it. User <codeph>anita</codeph> can grant SELECT permission
+on any or all of the columns of view <codeph>s.v</codeph> to anyone, even
+to users that do not have SELECT permission on <codeph>t1</codeph> or <codeph>t2</codeph>,
+or EXECUTE permission on <codeph>f</codeph>. User <codeph>anita</codeph>
grants
+SELECT permission on view <codeph>s.v</codeph> to user <codeph>harry</codeph>.
+When  user <codeph>harry</codeph> issues a SELECT statement on the view <codeph>s.v</codeph>,
<ph
+conref="devconrefs.dita#prod/productshortname"></ph> checks to determine if
+ user <codeph>harry</codeph> has SELECT permission on view<codeph>s.v</codeph>.
<ph
 conref="devconrefs.dita#prod/productshortname"></ph> does not check to determine
-if Harry has SELECT permission on <codeph>t1</codeph>, or <codeph>t2</codeph>,
-or EXECUTE permission on <codeph>f</codeph>. </p><p>Permissions on
triggers
-and constraints work the same way as permissions on views. When a view, trigger,
-or constraint is created, <ph conref="devconrefs.dita#prod/productshortname"></ph>
checks
+if  user <codeph>harry</codeph> has SELECT permission on <codeph>t1</codeph>,
+or <codeph>t2</codeph>, or EXECUTE permission on <codeph>f</codeph>.
</p><p>Permissions
+on triggers and constraints work the same way as permissions on views. When
+a view, trigger, or constraint is created, <ph conref="devconrefs.dita#prod/productshortname"></ph>
checks
 that the owner has the required permissions. Other users do not need to have
 those permissions to perform actions on a view, trigger, or constraint. </p><p>If
 the required permissions are revoked from the owner of a view, trigger, or

Modified: db/derby/docs/trunk/src/devguide/derbydev.ditamap
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/devguide/derbydev.ditamap?view=diff&rev=440851&r1=440850&r2=440851
==============================================================================
--- db/derby/docs/trunk/src/devguide/derbydev.ditamap (original)
+++ db/derby/docs/trunk/src/devguide/derbydev.ditamap Wed Sep  6 12:51:55 2006
@@ -1581,6 +1581,9 @@
 <relcell>
 <topicref href="cdevcsecure866060.dita" navtitle="Setting the SQL standard authorization
mode">
 </topicref>
+<topicref href="../ref/rrefsqljgrant.dita" navtitle="GRANT statement "></topicref>
+<topicref href="../ref/rrefsqljrevoke.dita" navtitle="REVOKE statement ">
+</topicref>
 </relcell>
 </relrow>
 <relrow>

Modified: db/derby/docs/trunk/src/ref/refderby.ditamap
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/ref/refderby.ditamap?view=diff&rev=440851&r1=440850&r2=440851
==============================================================================
--- db/derby/docs/trunk/src/ref/refderby.ditamap (original)
+++ db/derby/docs/trunk/src/ref/refderby.ditamap Wed Sep  6 12:51:55 2006
@@ -47,11 +47,27 @@
 <topicref href="../devguide/cdevcsecuregrantrevokeaccess.dita" navtitle="SQL standard
authorization">
 </topicref>
 <topicref href="rrefsqljgrant.dita" navtitle="GRANT statement "></topicref>
+<topicref href="rrefsistabssyscolperms.dita" navtitle="SYSCOLPERMS"></topicref>
+<topicref href="rrefsistabssystableperms.dita" navtitle="SYSTABLEPERMS"></topicref>
 </relcell>
 </relrow>
 <relrow>
-<relcell></relcell>
-<relcell></relcell>
+<relcell>
+<topicref href="rrefsistabssystableperms.dita" navtitle="SYSTABLEPERMS"></topicref>
+</relcell>
+<relcell>
+<topicref href="rrefsqljgrant.dita" navtitle="GRANT statement "></topicref>
+<topicref href="rrefsqljrevoke.dita" navtitle="REVOKE statement "></topicref>
+</relcell>
+</relrow>
+<relrow>
+<relcell>
+<topicref href="rrefsistabssyscolperms.dita" navtitle="SYSCOLPERMS"></topicref>
+</relcell>
+<relcell>
+<topicref href="rrefsqljgrant.dita" navtitle="GRANT statement "></topicref>
+<topicref href="rrefsqljrevoke.dita" navtitle="REVOKE statement "></topicref>
+</relcell>
 </relrow>
 </reltable>
 <topicref href="rrefcopyright.dita" navtitle="Copyright"></topicref>

Modified: db/derby/docs/trunk/src/ref/rrefsistabs12813.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/ref/rrefsistabs12813.dita?view=diff&rev=440851&r1=440850&r2=440851
==============================================================================
--- db/derby/docs/trunk/src/ref/rrefsistabs12813.dita (original)
+++ db/derby/docs/trunk/src/ref/rrefsistabs12813.dita Wed Sep  6 12:51:55 2006
@@ -48,7 +48,7 @@
 <entry colname="2">CHAR</entry>
 <entry colname="3">36</entry>
 <entry colname="4">false</entry>
-<entry colname="5">A uunique identifier for the dependent.</entry>
+<entry colname="5">A unique identifier for the dependent.</entry>
 </row>
 <row>
 <entry colname="1">DEPENDENTFINDER</entry>

Modified: db/derby/docs/trunk/src/ref/rrefsqljrevoke.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/ref/rrefsqljrevoke.dita?view=diff&rev=440851&r1=440850&r2=440851
==============================================================================
--- db/derby/docs/trunk/src/ref/rrefsqljrevoke.dita (original)
+++ db/derby/docs/trunk/src/ref/rrefsqljrevoke.dita Wed Sep  6 12:51:55 2006
@@ -2,28 +2,30 @@
  
 <!DOCTYPE reference PUBLIC "-//OASIS//DTD DITA Reference//EN"
  "reference.dtd">
-<!-- 
-Copyright 1997, 2005 The Apache Software Foundation or its licensors, as applicable.  
+<!--
+Licensed to the Apache Software Foundation (ASF) under one or more
+contributor license agreements.  See the NOTICE file distributed with 
+this work for additional information regarding copyright ownership.
+The ASF licenses this file to You under the Apache License, Version 2.0
+(the "License"); you may not use this file except in compliance with
+the License.  You may obtain a copy of the License at
 
-Licensed under the Apache License, Version 2.0 (the "License");  
-you may not use this file except in compliance with the License.  
-You may obtain a copy of the License at      
+http://www.apache.org/licenses/LICENSE-2.0
 
-http://www.apache.org/licenses/LICENSE-2.0  
-
-Unless required by applicable law or agreed to in writing, software  
-distributed under the License is distributed on an "AS IS" BASIS,  
-WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.  
-See the License for the specific language governing permissions and  
-limitations under the License.
--->
+Unless required by applicable law or agreed to in writing, software
+distributed under the License is distributed on an "AS IS" BASIS,
+WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+See the License for the specific language governing permissions and
+limitations under the License.-->
 <reference id="rrefsqljrevoke" xml:lang="en-us">
 <title>REVOKE statement </title>
 <shortdesc>Use the REVOKE statement to remove permissions from a specific
 user or from all users to perform actions on database objects.</shortdesc>
 <prolog><metadata>
-<keywords><indexterm>REVOKE statement</indexterm><indexterm>SQL statements<indexterm>REVOKE</indexterm></indexterm>
-</keywords>
+<keywords><indexterm>REVOKE statement<indexterm>syntax</indexterm></indexterm>
+<indexterm>SQL statements<indexterm>REVOKE</indexterm></indexterm><indexterm>REVOKE
+statement<indexterm>limitations</indexterm></indexterm><indexterm>privileges<indexterm>tables
+and columns, revoking</indexterm></indexterm></keywords>
 </metadata></prolog>
 <refbody>
 <section> <p>The following types of permissions can be revoked:<ul>
@@ -77,14 +79,14 @@
 only on the specified columns.</p></section>
 <section id="revokegrantees"><title>grantees</title><codeblock><b>{
<i>authorization ID</i> | PUBLIC } [,{ <i>authorization ID</i> | PUBLIC
} ] *</b
 ></codeblock><p>You can revoke the privileges from specific users or from
-all users. Use the keyword PUBLIC to specify all users. When PUBLIC is specified,
-the privileges affect all current and future users. The privileges revoked
-from PUBLIC and to individual users are independent privileges. For example,
+all users. Use the keyword PUBLIC to specify all users. The privileges revoked
+from PUBLIC and from individual users are independent privileges. For example,
 a SELECT privilege on table <codeph>t</codeph> is granted to both PUBLIC and
 to the authorization ID <codeph>harry</codeph>. The SELECT privilege is later
-revoked from the authorization ID <codeph>harry</codeph>, but Harry can access
-the table <codeph>t</codeph> through the PUBLIC privilege.</p><note
type="restriction">You
-cannot revoke the privileges of the owner of an object.</note></section>
+revoked from the authorization ID <codeph>harry</codeph>, but the authorization
+ID <codeph>harry</codeph> can access the table <codeph>t</codeph>
through
+the PUBLIC privilege.</p><note type="restriction">You cannot revoke the privileges
+of the owner of an object.</note></section>
 <section id="revokeroutinename"><title>routine-designator</title><codeblock><b>
   {
 		<i>qualified-name</i> [ signature ]
@@ -95,16 +97,71 @@
 not try to determine if you have other privileges that can replace the privileges
 that are being revoked. For more information, see "SQL standard authorization"
 in the <ph conref="refconrefs.dita#pub/citdevelop">Derby Developer's Guide</ph>.</p></section>
+<section><title>Limitations</title><p>The following limitations apply
to the
+REVOKE statement:</p><dl><dlentry>
+<dt>Table-level privileges</dt>
+<dd>All of the table-level privilege types for a specified grantee and table
+ID are stored in one row in the SYSTABLEPERMS system table. For example, when <codeph>user2</codeph>
is
+granted the SELECT and DELETE privileges on table <codeph>user1.t1</codeph>,
+a row is added to the SYSTABLEPERMS table. The GRANTEE field contains <codeph>user2</codeph>
and
+the TABLEID contains <codeph>user1.t1</codeph>. The SELECTPRIV and DELETEPRIV
+fields are set to Y. The remaining privilege type fields are set to N.<p>When
+a grantee creates an object that relies on one of the privilege types, the <ph
+conref="refconrefs.dita#prod/productshortname"></ph> engine tracks the dependency
+of the object on the specific row in the SYSTABLEPERMS table. For example, <codeph>user2</codeph>
creates
+the view <codeph>v1</codeph> by using the statement <codeph>SELECT * FROM
+user1.t1</codeph>, the dependency manager tracks the dependency of view <codeph>v1</codeph>
on
+the row in SYSTABLEPERMS for GRANTEE(<codeph>user2</codeph>), TABLEID(<codeph>user1.t1</codeph>).
+The dependency manager knows only that the view is dependent on a privilege
+type in that specific row, but does not track exactly which privilege type
+the view is dependent on.</p><p>When a REVOKE statement for a table-level
+privilege is issued for a grantee and table ID, all of the objects that are
+dependent on the grantee and table ID are dropped. For example, if <codeph>user1</codeph>
revokes
+the DELETE privilege on table <codeph>t1</codeph> from <codeph>user2</codeph>,
+the row in SYSTABLEPERMS for GRANTEE(<codeph>user2</codeph>), TABLEID(<codeph>user1.t1</codeph>)
+is modified by the REVOKE statement. The dependency manager sends a revoke
+invalidation message to the view <codeph>user2.v1</codeph> and the view is
+dropped even though the view is not dependent on the DELETE privilege for
+GRANTEE(<codeph>user2</codeph>), TABLEID(<codeph>user1.t1</codeph>).</p></dd>
+</dlentry><dlentry>
+<dt>Column-level privileges</dt>
+<dd>Only one type of privilege for a specified grantee and table ID are stored
+in one row in the SYSCOLPERMS system table. For example, when <codeph>user2</codeph>
is
+granted the SELECT privilege on table <codeph>user1.t1</codeph> for columns
+c12 and c13, a row is added to the SYSCOLPERMS. The GRANTEE field contains <codeph>user2</codeph>,
+the TABLEID contains <codeph>user1.t1</codeph>, the TYPE field contains <codeph>S</codeph>,
+and the COLUMNS field contains <codeph>c12, c13</codeph>.<p>When a grantee
+creates an object that relies on the privilege type and the subset of columns
+in a table ID, the <ph conref="refconrefs.dita#prod/productshortname"></ph> engine
+tracks the dependency of the object on the specific row in the SYSCOLPERMS
+table. For example, <codeph>user2</codeph> creates the view <codeph>v1</codeph>
by
+using the statement <codeph>SELECT c11 FROM user1.t1</codeph>, the dependency
+manager tracks the dependency of view <codeph>v1</codeph> on the row in SYSCOLPERMS
+for GRANTEE(<codeph>user2</codeph>), TABLEID(<codeph>user1.t1</codeph>),
TYPE(S).
+The dependency manager knows that the view is dependent on the SELECT privilege
+type, but does not track exactly which columns the view is dependent on.</p><p>When
+a REVOKE statement for a column-level privilege is issued for a grantee, table
+ID, and type, all of the objects that are dependent on the grantee, table
+ID, and type are dropped. For example, if <codeph>user1</codeph> revokes the
+SELECT privilege on column <codeph>c12</codeph> on table <codeph>user1.t1</codeph>
from <codeph>user2</codeph>,
+the row in SYSCOLPERMS for GRANTEE(<codeph>user2</codeph>), TABLEID(<codeph>user1.t1</codeph>),
+TYPE(S) is modified by the REVOKE statement. The dependency manager sends
+a revoke invalidation message to the view <codeph>user2.v1</codeph> and the
+view is dropped even though the view is not dependent on the column <codeph>c12</codeph>
for
+GRANTEE(<codeph>user2</codeph>), TABLEID(<codeph>user1.t1</codeph>),
TYPE(S).</p></dd>
+</dlentry></dl></section>
 <example> <title>Revoke examples</title><p>To revoke the SELECT privilege
-on table t from the authorization IDs <codeph>maria</codeph> and <codeph>harry</codeph>,
+on table <codeph>t</codeph> from the authorization IDs <codeph>maria</codeph>
and <codeph>harry</codeph>,
 use the following syntax:<codeblock><b>REVOKE SELECT ON TABLE t FROM maria,harry</b>
</codeblock></p><p>To
-revoke the UPDATE and TRIGGER privileges on table t from the authorization
-IDs <codeph>anita</codeph> and <codeph>zhi</codeph>, use the following
syntax:<codeblock><b>REVOKE UPDATE, TRIGGER ON TABLE t FROM anita,zhi</b>
</codeblock
-></p><p>To revoke the SELECT privilege on table s.v from all users, use the
-following syntax:<codeblock><b>REVOKE SELECT ON TABLE s.v FROM PUBLIC</b></codeblock></p><p>To
-revoke the UPDATE privilege on columns c1 and c2 of table s.v from all users,
-use the following syntax:<codeblock><b>REVOKE UPDATE (c1,c2) ON TABLE s.v FROM
PUBLIC</b></codeblock></p><p>To
-revoke the EXECUTE privilege on procedure p from the authorization ID <codeph>george</codeph>,
-use the following syntax:</p><codeblock><b>REVOKE EXECUTE ON PROCEDURE
p FROM george RESTRICT</b> </codeblock></example>
+revoke the UPDATE and TRIGGER privileges on table <codeph>t</codeph> from
+the authorization IDs <codeph>anita</codeph> and <codeph>zhi</codeph>,
use
+the following syntax:<codeblock><b>REVOKE UPDATE, TRIGGER ON TABLE t FROM anita,zhi</b>
</codeblock></p><p>To
+revoke the SELECT privilege on table <codeph>s.v</codeph> from all users,
+use the following syntax:<codeblock><b>REVOKE SELECT ON TABLE s.v FROM PUBLIC</b></codeblock></p><p>To
+revoke the UPDATE privilege on columns <codeph>c1</codeph> and <codeph>c2</codeph>
of
+table <codeph>s.v</codeph> from all users, use the following syntax:<codeblock><b>REVOKE
UPDATE (c1,c2) ON TABLE s.v FROM PUBLIC</b></codeblock></p
+><p>To revoke the EXECUTE privilege on procedure <codeph>p</codeph>
from the
+authorization ID <codeph>george</codeph>, use the following syntax:</p><codeblock><b>REVOKE
EXECUTE ON PROCEDURE p FROM george RESTRICT</b> </codeblock
+></example>
 </refbody>
 </reference>



Mime
View raw message