db-derby-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From chaa...@apache.org
Subject svn commit: r898089 - in /db/derby/docs/trunk/src: devguide/cdevcsecuregrantrevokeaccess.dita devguide/derbydev.ditamap ref/rrefsqlj13590.dita ref/rrefsqlj15446.dita ref/rrefsqlj43125.dita ref/rrefsqljgrant.dita ref/rrefsqljrevoke.dita
Date Mon, 11 Jan 2010 22:19:05 GMT
Author: chaase3
Date: Mon Jan 11 22:19:04 2010
New Revision: 898089

URL: http://svn.apache.org/viewvc?rev=898089&view=rev
Log:
DERBY-4505: Document that views, triggers, and constraints run with definer's rights rather
than invoker's rights

Modified 2 topics in Developer's Guide and 5 topics in Reference Manual.

Patch: DERBY-4505-2.diff

Modified:
    db/derby/docs/trunk/src/devguide/cdevcsecuregrantrevokeaccess.dita
    db/derby/docs/trunk/src/devguide/derbydev.ditamap
    db/derby/docs/trunk/src/ref/rrefsqlj13590.dita
    db/derby/docs/trunk/src/ref/rrefsqlj15446.dita
    db/derby/docs/trunk/src/ref/rrefsqlj43125.dita
    db/derby/docs/trunk/src/ref/rrefsqljgrant.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?rev=898089&r1=898088&r2=898089&view=diff
==============================================================================
--- db/derby/docs/trunk/src/devguide/cdevcsecuregrantrevokeaccess.dita (original)
+++ db/derby/docs/trunk/src/devguide/cdevcsecuregrantrevokeaccess.dita Mon Jan 11 22:19:04
2010
@@ -21,7 +21,7 @@
 <concept id="cdevcsecuregrantrevokeaccess" xml:lang="en-us">
 <title>Using SQL standard authorization</title>
 <shortdesc>When the SQL standard authorization mode is enabled, object owners
-can use the GRANT and REVOKE SQL statements to set the user permissions for
+can use the GRANT and REVOKE SQL statements to set the user privileges for
 specific database objects or for specific SQL actions. They can also use roles
 to administer privileges.</shortdesc>
 <prolog><metadata>
@@ -30,7 +30,10 @@
 authorizations<indexterm>PUBLIC</indexterm></indexterm><indexterm>GRANT
statement<indexterm>overview</indexterm></indexterm>
 <indexterm>REVOKE statement<indexterm>overview</indexterm></indexterm><indexterm>access
 control system<indexterm>SQL2003</indexterm></indexterm><indexterm>SQL
standard
-authorization mode</indexterm></keywords>
+authorization mode</indexterm>
+<indexterm>invoker rights<indexterm>versus definer rights</indexterm></indexterm>
+<indexterm>definer rights<indexterm>versus invoker rights</indexterm></indexterm>
+</keywords>
 </metadata></prolog>
 <conbody>
 <p>The SQL standard authorization mode is a SQL2003 compatible access control
@@ -44,9 +47,9 @@
 conref="../conrefs.dita#prod/productshortname"></ph> SQL authorization mode
 provides a more precise mechanism to limit the actions that users can take
 on the database.</p>
-<p>The GRANT statement is used to grant specific permissions to users or to
+<p>The GRANT statement is used to grant specific privileges to users or to
 roles, or to grant roles to users or to roles. The
-REVOKE statement is used to revoke permissions and role grants. The grant and
+REVOKE statement is used to revoke privileges and role grants. The grant and
 revoke privileges are:<ul>
 <li>DELETE</li>
 <li>EXECUTE</li>
@@ -63,6 +66,11 @@
 have full privileges on the object.
 No other users have privileges on the object until the object owner grants
 privileges to them.</p>
+<p>Another way of saying that privileges on objects belong to the owner is to
+call them <term>definer rights</term>, as opposed to <term>invoker rights</term>.
+This is the terminology used by the SQL standard.</p>
+<p>See the <cite><ph conref="../conrefs.dita#pub/citref"></ph></cite>
for more
+information on the GRANT and REVOKE statements.</p>
 <section><title>Public and individual user privileges</title><p>The
object
 owner can grant and revoke privileges for specific users, for specific roles,
 or for all users.
@@ -81,7 +89,7 @@
 to determine if you have the required privileges at the PUBLIC level. If you
 have the PUBLIC level privileges, the object is created and is dependent on
 that PUBLIC level privilege. After the object is created, if the privilege
-on which the object depends on is revoked, the object is automatically dropped. <ph
+on which the object depends is revoked, the object is automatically dropped. <ph
 conref="../conrefs.dita#prod/productshortname"></ph> does not try to determine
 if you have other privileges that can replace the privileges that are being
 revoked. <dl><dlentry>
@@ -90,58 +98,27 @@
 SELECT privileges to user <codeph>harry</codeph> on table <codeph>t1</codeph>.
 User <codeph>zhi</codeph> grants SELECT privileges to PUBLIC on table <codeph>t1</codeph>.
 User <codeph>harry</codeph> creates view <codeph>v1</codeph> with
the statement
-SELECT * from <codeph>zhi.t1</codeph>. The view depends on the user-level
+<codeph>SELECT * from zhi.t1</codeph>. The view depends on the user-level
 privilege that user <codeph>harry</codeph> has on <codeph>t1</codeph>.
Subsequently,
 user <codeph>zhi</codeph> revokes SELECT privileges from user <codeph>harry</codeph>
on
 table <codeph>t1</codeph>. As a result, the view <codeph>harry.v1</codeph>
is
-dropped. </dd>
+dropped.</dd>
 </dlentry><dlentry>
 <dt>Example 2</dt>
 <dd>User <codeph>anita</codeph> creates table <codeph>t1</codeph>
and grants
 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
+the statement <codeph>SELECT * from 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>
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
+The view <codeph>harry.v1</codeph> continues to depend on the 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. 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>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 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="../conrefs.dita#prod/productshortname"></ph> checks to determine if
- user <codeph>harry</codeph> has SELECT permission on view<codeph>s.v</codeph>.
<ph
-conref="../conrefs.dita#prod/productshortname"></ph> does not check to determine
-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="../conrefs.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
-constraint, the object is dropped as part of the REVOKE statement.</p><p>See
-the <cite><ph conref="../conrefs.dita#pub/citref"></ph></cite> for
more
-information on the GRANT and REVOKE statements.</p></section>
+</dlentry></dl>
+<p>See
+<xref href="cdevcsecureprivileges.dita#cdevcsecureprivileges"></xref> for
+more information.</p></note></section>
 </conbody>
 </concept>

Modified: db/derby/docs/trunk/src/devguide/derbydev.ditamap
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/devguide/derbydev.ditamap?rev=898089&r1=898088&r2=898089&view=diff
==============================================================================
--- db/derby/docs/trunk/src/devguide/derbydev.ditamap (original)
+++ db/derby/docs/trunk/src/devguide/derbydev.ditamap Mon Jan 11 22:19:04 2010
@@ -2172,6 +2172,7 @@
 </topicref>
 <topicref collection-type="family" href="cdevcsecure866060.dita" navtitle="Setting the
SQL standard authorization mode">
 <topicref href="cdevcsecuregrantrevokeaccess.dita" navtitle="Using SQL standard authorization"></topicref>
+<topicref href="cdevcsecureprivileges.dita" navtitle="Privileges on views, triggers, and
constraints"></topicref>
 <topicref href="cdevcsecureroles.dita" navtitle="Using SQL roles"></topicref>
 <topicref href="rdevcsecuresqlauthexceptions.dita" navtitle="SQL standard authorization
exceptions"></topicref>
 </topicref>

Modified: db/derby/docs/trunk/src/ref/rrefsqlj13590.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/ref/rrefsqlj13590.dita?rev=898089&r1=898088&r2=898089&view=diff
==============================================================================
--- db/derby/docs/trunk/src/ref/rrefsqlj13590.dita (original)
+++ db/derby/docs/trunk/src/ref/rrefsqlj13590.dita Mon Jan 11 22:19:04 2010
@@ -75,7 +75,12 @@
 have the same function; the difference is in where you specify them. Table
 constraints allow you to specify more than one column in a PRIMARY KEY, UNIQUE,
 CHECK, or FOREIGN KEY constraint definition. Column-level constraints (except
-for check constraints) refer to only one column.</p></section>
+for check constraints) refer to only one column.</p>
+<p>A constraint operates with the privileges of the owner of the constraint.
+See "Using SQL standard authorization" and "Privileges on views, triggers, and
+constraints" in the <ph conref="../conrefs.dita#pub/citdevelop"></ph> for
+details.</p>
+</section>
 <refsyn><title>Syntax</title> </refsyn>
 <section><title>Primary key constraints</title> <p><indexterm>Primary
 key constraints</indexterm>A primary

Modified: db/derby/docs/trunk/src/ref/rrefsqlj15446.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/ref/rrefsqlj15446.dita?rev=898089&r1=898088&r2=898089&view=diff
==============================================================================
--- db/derby/docs/trunk/src/ref/rrefsqlj15446.dita (original)
+++ db/derby/docs/trunk/src/ref/rrefsqlj15446.dita Mon Jan 11 22:19:04 2010
@@ -27,7 +27,11 @@
 <refbody>
 <section> <p>Views are virtual tables formed by a query. A view is a dictionary
 object that you can use until you drop it. Views are not updatable.</p><p>If
-a qualified view name is specified, the schema name cannot begin with <i>SYS</i>.</p><p>The
+a qualified view name is specified, the schema name cannot begin with <i>SYS</i>.</p>
+<p>A view operates with the privileges of the owner of the view. See "Using SQL
+standard authorization" and "Privileges on views, triggers, and constraints" in
+the <ph conref="../conrefs.dita#pub/citdevelop"></ph> for details.</p>
+<p>The
 view owner automatically gains the SELECT privilege on the view. The SELECT
 privilege cannot be revoked from the view owner. The 
 <xref href="rrefattrib26867.dita#rrefattrib26867">database owner</xref>

Modified: db/derby/docs/trunk/src/ref/rrefsqlj43125.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/ref/rrefsqlj43125.dita?rev=898089&r1=898088&r2=898089&view=diff
==============================================================================
--- db/derby/docs/trunk/src/ref/rrefsqlj43125.dita (original)
+++ db/derby/docs/trunk/src/ref/rrefsqlj43125.dita Mon Jan 11 22:19:04 2010
@@ -44,7 +44,12 @@
 where you are the schema owner. To create a trigger on a table that you do
 not own, you must be granted the TRIGGER privilege on that table. The 
 <xref href="rrefattrib26867.dita#rrefattrib26867">database owner</xref>
-can also create triggers on any table in any schema.</p><p>The trigger
+can also create triggers on any table in any schema.</p>
+<p>A trigger operates with the privileges of the owner of the trigger. See
+"Using SQL standard authorization" and "Privileges on views, triggers, and
+constraints" in the <ph conref="../conrefs.dita#pub/citdevelop"></ph> for
+details.</p>
+<p>The trigger
 does not need to reside in the same schema as the table on which the trigger
 is defined.</p><p>If a qualified trigger name is specified, the schema name
 cannot begin with <i>SYS</i>.</p></section>

Modified: db/derby/docs/trunk/src/ref/rrefsqljgrant.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/ref/rrefsqljgrant.dita?rev=898089&r1=898088&r2=898089&view=diff
==============================================================================
--- db/derby/docs/trunk/src/ref/rrefsqljgrant.dita (original)
+++ db/derby/docs/trunk/src/ref/rrefsqljgrant.dita Mon Jan 11 22:19:04 2010
@@ -22,7 +22,7 @@
 -->
 <reference id="rrefsqljgrant" xml:lang="en-us">
 <title>GRANT statement </title>
-<shortdesc>Use the GRANT statement to give permissions to a specific user or
+<shortdesc>Use the GRANT statement to give privileges to a specific user or
 role, or to all users, to perform actions on database objects. You can also use
 the GRANT statement to grant a role to a user, to PUBLIC, or to another role.
 </shortdesc>
@@ -31,7 +31,7 @@
 </keywords>
 </metadata></prolog>
 <refbody>
-<section> <p>The following types of permissions can be granted:<ul>
+<section> <p>The following types of privileges can be granted:<ul>
 <li>Delete data from a specific table.</li>
 <li>Insert data into a specific table.</li>
 <li>Create a foreign key reference to the named table or to a subset of columns
@@ -43,9 +43,11 @@
 </ul></p><p>Before you issue a GRANT statement, check that the
 <codeph><xref href="rrefpropersqlauth.dita#rrefpropersqlauth">derby.database.sqlAuthorization</xref></codeph>
property
 is set to <codeph>true</codeph>. The <codeph>derby.database.sqlAuthorization</codeph>
property
-enables the SQL Authorization mode.</p><p>You can grant privileges to database
-objects that you are authorized to grant. See the CREATE statement for the
-database object that you want to grant privileges on for more information.</p><p>The
+enables the SQL Authorization mode.</p><p>You can grant privileges on an
+object if you are the owner of the object or the
+<xref href="rrefattrib26867.dita#rrefattrib26867">database owner</xref>. See
the
+CREATE statement for the database object that you want to grant privileges on
+for more information.</p><p>The
 syntax that you use for the GRANT statement depends on whether you are granting
 privileges to a table or to a routine, or granting a role.</p>
 <p>For more information on using the GRANT statement, see "Using SQL standard
@@ -87,7 +89,7 @@
 </b></codeblock></section>
 <section id="grantcollist"><title>column list</title><codeblock><b>
 ( column-identifier {, column-identifier}* )
 </b></codeblock></section>
-<section><p>Use the ALL PRIVILEGES privilege type to grant all of the permissions
+<section><p>Use the ALL PRIVILEGES privilege type to grant all of the privileges
 to the user or role for the specified table. You can also grant one or more table
 privileges by specifying a privilege-list.</p><p>Use the DELETE privilege
 type to grant permission to delete rows from the specified table.</p><p>Use
@@ -104,7 +106,7 @@
 the UPDATE privilege type to grant permission to use the UPDATE statement
 on the specified table. If a column list is specified, the permission applies
 only to the specified columns. To update a row using a statement that includes
-a WHERE clause, you must have SELECT permission on the columns in the row
+a WHERE clause, you must have the SELECT privilege on the columns in the row
 that you want to update. </p></section>
 <section id="grantgrantees"><title>grantees</title>
 <codeblock><b>{ <i><xref href="rrefrauthid.dita#rrefrauthid">AuthorizationIdentifier</xref></i>
| <i><xref href="rrefrolename.dita#rrefrolename">roleName</xref></i>
| PUBLIC } 

Modified: db/derby/docs/trunk/src/ref/rrefsqljrevoke.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/ref/rrefsqljrevoke.dita?rev=898089&r1=898088&r2=898089&view=diff
==============================================================================
--- db/derby/docs/trunk/src/ref/rrefsqljrevoke.dita (original)
+++ db/derby/docs/trunk/src/ref/rrefsqljrevoke.dita Mon Jan 11 22:19:04 2010
@@ -19,7 +19,7 @@
 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
+<shortdesc>Use the REVOKE statement to remove privileges from a specific
 user or role, or from all users, to perform actions on database objects. You can
 also use the REVOKE statement to revoke a role from a user, from PUBLIC, or from
 another role.</shortdesc>
@@ -30,7 +30,7 @@
 and columns, revoking</indexterm></indexterm></keywords>
 </metadata></prolog>
 <refbody>
-<section> <p>The following types of permissions can be revoked:<ul>
+<section> <p>The following types of privileges can be revoked:<ul>
 <li>Delete data from a specific table.</li>
 <li>Insert data into a specific table.</li>
 <li>Create a foreign key reference to the named table or to a subset of columns
@@ -81,7 +81,7 @@
   TRIGGER |
   UPDATE [<i>column list</i>] </b></codeblock></section>
 <section id="revokecollist"><title>column list</title><codeblock><b>
 ( column-identifier {, column-identifier}* ) </b></codeblock></section>
-<section><p>Use the ALL PRIVILEGES privilege type to revoke all of the permissions
+<section><p>Use the ALL PRIVILEGES privilege type to revoke all of the privileges
 from the user or role for the specified table. You can also revoke one or more table
 privileges by specifying a privilege-list.</p><p>Use the DELETE privilege
 type to revoke permission to delete rows from the specified table.</p><p>Use
@@ -96,7 +96,7 @@
 is valid on all of the columns in the table.</p><p>Use the TRIGGER privilege
 type to revoke permission to create a trigger on the specified table.</p><p>Use
 the UPDATE privilege type to revoke permission to use the UPDATE statement
-on the specified table. If a column list is specified, the permission is revoked
+on the specified table. If a column list is specified, the privilege is revoked
 only on the specified columns.</p></section>
 <section id="revokegrantees"><title>grantees</title>
 <codeblock><b>{ <i><xref href="rrefrauthid.dita#rrefrauthid">AuthorizationIdentifier</xref></i>
| <i><xref href="rrefrolename.dita#rrefrolename">roleName</xref></i>
| PUBLIC } 
@@ -137,8 +137,9 @@
 and constraints, if the privilege on which the object depends on is revoked,
 the object is automatically dropped. <ph conref="../conrefs.dita#prod/productshortname"></ph>
does
 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="../conrefs.dita#pub/citdevelop"></ph>.</p></section>
+that are being revoked. For more information, see "Using SQL standard
+authorization" and "Privileges on views, triggers, and constraints" in the
+<ph conref="../conrefs.dita#pub/citdevelop"></ph>.</p></section>
 <section><title>Limitations</title><p>The following limitations apply
to the
 REVOKE statement:</p><dl><dlentry>
 <dt>Table-level privileges</dt>



Mime
View raw message