db-derby-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From chaa...@apache.org
Subject svn commit: r772999 - /db/derby/docs/branches/10.5/src/devguide/cdevcsecureroles.dita
Date Fri, 08 May 2009 14:17:38 GMT
Author: chaase3
Date: Fri May  8 14:17:37 2009
New Revision: 772999

URL: http://svn.apache.org/viewvc?rev=772999&view=rev
DERBY-4161: SQL Roles - Clarify documentation regarding the SET ROLE

Merged DERBY-4161-2.diff to 10.5 docs branch from trunk revision 772996.


Modified: db/derby/docs/branches/10.5/src/devguide/cdevcsecureroles.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/branches/10.5/src/devguide/cdevcsecureroles.dita?rev=772999&r1=772998&r2=772999&view=diff
--- db/derby/docs/branches/10.5/src/devguide/cdevcsecureroles.dita (original)
+++ db/derby/docs/branches/10.5/src/devguide/cdevcsecureroles.dita Fri May  8 14:17:37 2009
@@ -59,30 +59,30 @@
 role A is the union of the privileges granted to role A and the privileges
 granted to any contained roles of role A.</p>
 <p>For example, suppose the database owner issued the following statements:</p>
-<codeblock>  create role readUser;
-  create role updateUser;
+<codeblock>  create role reader;
+  create role updater;
   create role taskLeaderA;
   create role taskLeaderB;
   create role projectLeader;
-  grant readUser to updateUser;
-  grant updateUser to taskLeaderA;
-  grant updateUser to taskLeaderB;
+  grant reader to updater;
+  grant updater to taskLeaderA;
+  grant updater to taskLeaderB;
   grant taskLeaderA to projectLeader;
   grant taskLeaderB to projectLeader;
 <p>The roles would then have the following containment relationships:</p>
-<codeblock>                   readUser
-                       |
-                       v
-                   updateUser
-                 /           \
-      taskLeaderA            taskLeaderB
-                 \           /
-                  projectLeader  
+<codeblock>                   reader
+                     |
+                     v
+                  updater
+                 /       \
+       taskLeaderA       taskLeaderB
+                 \       /
+               projectLeader  
 <p>In this case, the <codeph>projectLeader</codeph> role contains all the
 roles and has all their privileges. If the database owner then revokes
-<codeph>updateUser</codeph> from <codeph>taskLeaderA</codeph>,
+<codeph>updater</codeph> from <codeph>taskLeaderA</codeph>,
 <codeph>projectLeader</codeph> still contains that role through
 <p>The SYSCS_DIAG.CONTAINED_ROLES diagnostic table function can be used to
@@ -90,19 +90,27 @@
 <p>Cycles are not permitted in role grants. That is, if a role contains another
 role, you cannot grant the container role to the contained role. For example,
 the following statement would not be permitted:</p>
-<codeblock>grant projectLeader to updateUser;</codeblock>
+<codeblock>grant projectLeader to updater;</codeblock>
 <section><title>Setting roles</title>
-<p>When you first connect to
+<p>When a user first connects to
 <ph conref="../conrefs.dita#prod/productshortname"></ph>, no role is set, and
-the CURRENT_ROLE function returns null. During a session, you can call the SET
-ROLE statement to set the current role for that session. The role you set can be
+the CURRENT_ROLE function returns null. During a session, the user can call the
+SET ROLE statement to set the current role for that session. The role can be
 any role that has been granted to the session's current user or to PUBLIC. To
 unset the current role, call SET ROLE with an argument of NONE. At any time
 during a session, there is always a current user, but there is a current role
 only if SET ROLE has been called with an argument other than NONE. If a current
-role is not set, the session has only the privileges granted to you directly or
-to PUBLIC.</p>
+role is not set, the session has only the privileges granted to the user
+directly or to PUBLIC.</p>
+<p>For example, if the database owner created and granted the roles shown in the
+previous session, a user would have to issue a SET ROLE statement to have them
+take effect. Suppose a user issued the following statement:</p>
+<codeblock>SET ROLE taskLeaderA;</codeblock>
+<p>Assuming that the database owner had granted the <codeph>taskLeaderA</codeph>
+role to the user, the user would be allowed to set the role as shown and would
+have all the privileges granted to the <codeph>taskLeaderA</codeph>,
+<codeph>updater</codeph>, and <codeph>reader</codeph> roles.</p>
 <p>To retrieve the current role identifier in SQL, call the CURRENT_ROLE
 <p>Within stored procedures and functions that contain SQL, the current role is
@@ -120,10 +128,10 @@
 can grant privileges on tables and routines to that role. You can grant the same
 privileges to roles that you can grant to users. Granting a privilege to a role
 implicitly grants privileges to all roles that contain that role. For example,
-if you grant delete privileges on a table to <codeph>updateUser</codeph>, every
-user in the <codeph>updateUser</codeph>, <codeph>taskLeaderA</codeph>,
+if you grant delete privileges on a table to <codeph>updater</codeph>, every
+user in the <codeph>updater</codeph>, <codeph>taskLeaderA</codeph>,
 <codeph>taskLeaderB</codeph>, and <codeph>projectLeader</codeph>
role will also
-have delete privileges on that table, but users in the <codeph>readUser</codeph>
+have delete privileges on that table, but users in the <codeph>reader</codeph>
 role will not.</p>
 <section><title>Revoking privileges from a role</title>

View raw message