svn commit: r1150905 - /db/derby/docs/trunk/src/devguide/cdevcsecureroles.dita

[da...@apache.org]

Author: dag
Date: Mon Jul 25 20:55:35 2011
New Revision: 1150905

URL: http://svn.apache.org/viewvc?rev=1150905&view=rev
Log:
DERBY-5350 Devguide needs update for definer's rights

Patch derby-5350b which makes the required update.


Modified:
    db/derby/docs/trunk/src/devguide/cdevcsecureroles.dita

Modified: db/derby/docs/trunk/src/devguide/cdevcsecureroles.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/devguide/cdevcsecureroles.dita?rev=1150905&r1=1150904&r2=1150905&view=diff
==============================================================================
--- db/derby/docs/trunk/src/devguide/cdevcsecureroles.dita (original)
+++ db/derby/docs/trunk/src/devguide/cdevcsecureroles.dita Mon Jul 25 20:55:35 2011
@@ -113,15 +113,34 @@ have all the privileges granted to the <
 <codeph>updater</codeph>, and <codeph>reader</codeph> roles.</p>
 <p>To retrieve the current role identifier in SQL, call the CURRENT_ROLE
 function.</p>
-<p>Within stored procedures and functions that contain SQL, the current role is
-on the authorization stack. Initially, inside a nested connection, the current
-role is set to that of the calling context. Upon return from the stored
-procedure or function, the authorization stack is popped, so the current role
-of the calling context is not affected by any setting of the role inside the
-called procedure or function. If the stored procedure opens more than one
-nested connection, these all share the same (stacked) current role state. Any
-dynamic result set passed out of a stored procedure sees the current role of
-the nested context.</p>
+<p>Within stored procedures and functions that contain SQL, the
+  current role depends on whether the routine executes with invoker's
+  rights or with definer's rights, as specified by the EXTERNAL SECURITY clause in
+  the CREATE FUNCTION or CREATE PROCEDURE statements in
+  the <ph conref="../conrefs.dita#pub/citref"></ph>. During execution,
+  the current user and current role are kept on an authorization stack
+  which is pushed during a stored routine call.
+</p>
+
+<p>Within routines that execute with invoker's rights, the following
+applies: initially, inside a nested connection, the current role is
+set to that of the calling context. So is the current user. Such
+routines may set any role granted to the invoker or to PUBLIC.</p>
+
+<p>Within routines that execute with definer's rights, the following
+applies: initially, inside a nested connection, the current role is
+NULL, and the current user is that of the definer. Such routines may
+set any role granted to the definer or to PUBLIC.
+</p>
+<p>
+Upon return from the stored procedure or function, the authorization
+stack is popped, so the current role of the calling context is not
+affected by any setting of the role inside the called procedure or
+function.  If the stored procedure opens more than one nested
+connection, these all share the same (stacked) current role (and user)
+state. Any dynamic result set passed out of a stored procedure sees
+the current role (or user) of the nested context.
+</p>
 </section>
 <section><title>Granting privileges to roles</title>
 <p>Once a role has been created, both the database owner and the object owner