Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <8311836.1156977983352.JavaMail.jira@brutus>
Date: Wed, 30 Aug 2006 15:46:23 -0700 (PDT)
From: "Laura Stewart (JIRA)" <derby-dev@db.apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Commented: (DERBY-1646) Documentation to address
 Grant/Revoke Authorization for
 views/triggers/constraints/routines(DERBY-1330)
In-Reply-To: <26339948.1154713813839.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

    [ http://issues.apache.org/jira/browse/DERBY-1646?page=comments#action_12431735 ] 
            
Laura Stewart commented on DERBY-1646:
--------------------------------------

Hi Mamta - 

I ahve drafted the text for the table-level limitation. Please look it over and see if I have captured what  you want.

Limitations

Table-level privileges
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 user2 is granted the SELECT and DELETE privileges on table user1.t1, a row is added to the SYSTABLEPERMS table. The GRANTEE field contains user2 and the TABLEID contains user1.t1. The SELECTPRIV and DELETEPRIV fields are set to Y. The remaining privilege type fields are set to N.

When a grantee creates an object that relies on one of the privilege types, the Derby engine tracks the dependency of the object on the specific row in the SYSTABLEPERMS table. For example, user2 creates the view v1 by using the statement SELECT * FROM user1.t1, the dependency manager tracks the dependency of view v1 on the row in SYSTABLEPERMS for GRANTEE(user2), TABLEID(user1.t1). 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.

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 user1 revokes the DELETE privilege on table t1 from user2, the row in SYSTABLEPERMS for GRANTEE(user2), TABLEID(user1.t1) is modified by the REVOKE statement. The dependency manager sends a revoke invalidation message to the view user2.v1 and the view is dropped even though the view is not dependent on the DELETE privilege for GRANTEE(user2), TABLEID(user1.t1).


> Documentation to address Grant/Revoke Authorization for views/triggers/constraints/routines(DERBY-1330)
> -------------------------------------------------------------------------------------------------------
>
>                 Key: DERBY-1646
>                 URL: http://issues.apache.org/jira/browse/DERBY-1646
>             Project: Derby
>          Issue Type: New Feature
>          Components: Documentation
>    Affects Versions: 10.2.1.0
>            Reporter: Mamta A. Satoor
>         Assigned To: Laura Stewart
>             Fix For: 10.2.1.0
>
>
> Creating a separate jira entry for documentation of Grant/Revoke Authorization for views/triggers/constraints/routines(Engine changes are going as part of DERBY-1330).
> Will link this jira entry to DERBY-1330

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira