Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <28129800.1151446231292.JavaMail.jira@brutus>
Date: Tue, 27 Jun 2006 22:10:31 +0000 (GMT+00:00)
From: "Mamta A. Satoor (JIRA)" <derby-dev@db.apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Updated: (DERBY-1330) Provide runtime privilege checking for
 grant/revoke functionality
In-Reply-To: <14984243.1147927445981.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

     [ http://issues.apache.org/jira/browse/DERBY-1330?page=3Dall ]

Mamta A. Satoor updated DERBY-1330:
-----------------------------------

    Attachment: Derby1330ViewPrivilegeCollectionV1diff.txt
                Derby1330ViewPrivilegeCollectionV1stat.txt

I have been working on storing privilege requirements for view (in Derby SQ=
L Authorization mode only) during create view time in SYSDEPENDS table. Thi=
s information in SYSDEPENDS will later be used at the revoke privilege time=
. That patch for this work is attached as Derby1330ViewPrivilegeCollectionV=
1diff.txt to this JIRA entry. All the views that depend on the privilege be=
ing revoked will be dropped. The revoke privilege work to drop affected vie=
ws is not included in this patch.

The patch has 2 major components to it
1)If the query for create view is accessing view/s, then Derby engine flatt=
ens all those view/s. Once the view flattening is finished, Derby engine go=
es through all the columns for the flattened parent sql and it starts build=
ing the privilege requirement for those columns. But since views are always=
 accessed with definer's privileges (which means that as long as a user has=
 privilege to access a view, the user can select from the view. This works =
even if the user does not need direct privileges to the objects accessed by=
 the view.), Derby engine should not collect privilege requirements for obj=
ects accessed by views. In order to implement this behavior, I have added a=
 flag to QueryTreeNode which will be set to false if the object is going to=
 be accessed with definer's privileges. During view flattening, the objects=
 accessed by view will be marked with definer privileges. Later, when the D=
erby enging goes through all the columns, it will check if the column is ma=
rked with definer's privilege and if so, then do not look for privilege req=
uirement for that column.=20
2)Once the privileges have been collected for the create view in the bind p=
hase, they need to be recorded in SYSDEPENDS table during the execution pha=
se of the create view sql. SYSDEPENDS will add one row for every privilege =
requirement for the view. The DEPENDENTID will be view descriptor and PROVI=
DERID has to be a unique id to identify permission descriptor's uniquely. I=
n order to do this, PermissionsDescriptor needs to implement interface Prov=
ider and it needs to have a UUID associated with it. This required addition=
 of a UUID column in SYSTABLEPERMS, SYSCOLPERMS and SYSROUTINEPERMS. This U=
UID is required by the DependencyManager to uniquely identify a row for a g=
iven PROVIDERID.=20

The patch mail to the derby developer list can be found at http://www.nabbl=
e.com/-PATCH-DERBY-1330-Collect-privilege-requirements-for-views-tf1858264.=
html#a5075008. This thread has more information about individual class chan=
ges.

> Provide runtime privilege checking for grant/revoke functionality
> -----------------------------------------------------------------
>
>          Key: DERBY-1330
>          URL: http://issues.apache.org/jira/browse/DERBY-1330
>      Project: Derby
>         Type: Sub-task

>   Components: SQL
>     Versions: 10.2.0.0
>     Reporter: Mamta A. Satoor
>  Attachments: AuthorizationModelForDerbySQLStandardAuthorization.html, Au=
thorizationModelForDerbySQLStandardAuthorizationV2.html, Derby1330ViewPrivi=
legeCollectionV1diff.txt, Derby1330ViewPrivilegeCollectionV1stat.txt
>
> Additional work needs to be done for grant/revoke to make sure that only =
users with required privileges can access various database objects. In orde=
r to do that, first we need to collect the privilege requirements for vario=
us database objects and store them in SYS.SYSREQUIREDPERM. Once we have thi=
s information then when a user tries to access an object, the required SYS.=
SYSREQUIREDPERM privileges for the object will be checked against the user =
privileges in SYS.SYSTABLEPERMS, SYS.SYSCOLPERMS and SYS.SYSROUTINEPERMS. T=
he database object access will succeed only if the user has the necessary p=
rivileges.
> SYS.SYSTABLEPERMS, SYS.SYSCOLPERMS and SYS.SYSROUTINEPERMS are already po=
pulated by Satheesh's work on DERBY-464. But SYS.SYSREQUIREDPERM doesn't ha=
ve any information in it at this point and hence no runtime privilege check=
ing is getting done at this point.

--=20
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