Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <27721843.1156321694889.JavaMail.jira@brutus>
Date: Wed, 23 Aug 2006 01:28:14 -0700 (PDT)
From: "Yip Ng (JIRA)" <derby-dev@db.apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Commented: (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=3Dcomments#actio=
n_12429933 ]=20
           =20
Yip Ng commented on DERBY-1330:
-------------------------------

It seems that the getTablePermissions( UUID ) method in DataDictionaryImpl =
might be problematic.
This method is called when the dependency manager needs to get a dependable=
 via its provider id. (tableperms id)
(i.e.:  getPersistentProviderInfos() of the dependency manager)

In getTablePermissions(UUID), the TablePermsDescriptor constructor will set=
 its member vars grantee and TableUUID=20
to null since the row in sys.systableperms can be located via tablePermsUUI=
D (instead of tableUUID, grantor and grantee).  But during getPermissions()=
 processing, the hashCode() of the TablePermsDescriptor will be invoked by =
the permissionCache which eventually will lead to a call to grantee.hashCod=
e(); thus, resulting in NullPointerException.


public TablePermsDescriptor getTablePermissions( UUID tablePermsUUID) throw=
s StandardException {
    TablePermsDescriptor key =3D new TablePermsDescriptor( this, tablePerms=
UUID);
    return (TablePermsDescriptor) getPermissions( key);
}


> Provide runtime privilege checking for grant/revoke functionality
> -----------------------------------------------------------------
>
>                 Key: DERBY-1330
>                 URL: http://issues.apache.org/jira/browse/DERBY-1330
>             Project: Derby
>          Issue Type: Sub-task
>          Components: SQL
>    Affects Versions: 10.2.1.0
>            Reporter: Mamta A. Satoor
>         Assigned To: Mamta A. Satoor
>         Attachments: AuthorizationModelForDerbySQLStandardAuthorization.h=
tml, AuthorizationModelForDerbySQLStandardAuthorizationV2.html, DERBY1330ja=
vaDocWarningsDiffV9.txt, DERBY1330javaDocWarningsStatV9.txt, Derby1330Minor=
CleanupV7diff.txt, Derby1330MinorCleanupV7stat.txt, Derby1330PrivilegeColle=
ctionV2diff.txt, Derby1330PrivilegeCollectionV2stat.txt, Derby1330Privilege=
CollectionV3diff.txt, Derby1330PrivilegeCollectionV3stat.txt, Derby1330setU=
UIDinDataDictionaryV10diff.txt, Derby1330setUUIDinDataDictionaryV10stat.txt=
, Derby1330setUUIDinDataDictionaryV8diff.txt, Derby1330setUUIDinDataDiction=
aryV8stat.txt, Derby1330uuidIndexForPermsSystemTablesV4diff.txt, Derby1330u=
uidIndexForPermsSystemTablesV4stat.txt, Derby1330uuidIndexForPermsSystemTab=
lesV5diff.txt, Derby1330uuidIndexForPermsSystemTablesV5stat.txt, Derby1330u=
uidIndexForPermsSystemTablesV6diff.txt, Derby1330uuidIndexForPermsSystemTab=
lesV6stat.txt, Derby1330ViewPrivilegeCollectionV1diff.txt, Derby1330ViewPri=
vilegeCollectionV1stat.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: htt=
p://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira