From derby-dev-return-24263-apmail-db-derby-dev-archive=db.apache.org@db.apache.org Tue Jul 18 16:06:25 2006 Return-Path: Delivered-To: apmail-db-derby-dev-archive@www.apache.org Received: (qmail 9424 invoked from network); 18 Jul 2006 16:06:25 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 18 Jul 2006 16:06:25 -0000 Received: (qmail 39524 invoked by uid 500); 18 Jul 2006 16:06:24 -0000 Delivered-To: apmail-db-derby-dev-archive@db.apache.org Received: (qmail 39462 invoked by uid 500); 18 Jul 2006 16:06:24 -0000 Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: Delivered-To: mailing list derby-dev@db.apache.org Received: (qmail 39453 invoked by uid 99); 18 Jul 2006 16:06:24 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 18 Jul 2006 09:06:24 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received: from [209.237.227.198] (HELO brutus.apache.org) (209.237.227.198) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 18 Jul 2006 09:06:23 -0700 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id 424F641001C for ; Tue, 18 Jul 2006 16:04:15 +0000 (GMT) Message-ID: <4454259.1153238655269.JavaMail.jira@brutus> Date: Tue, 18 Jul 2006 09:04:15 -0700 (PDT) From: "Mamta A. Satoor (JIRA)" 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: 7bit X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N [ http://issues.apache.org/jira/browse/DERBY-1330?page=all ] Mamta A. Satoor updated DERBY-1330: ----------------------------------- Attachment: Derby1330setUUIDinDataDictionaryV8diff.txt Derby1330setUUIDinDataDictionaryV8stat.txt Currently, in case of revoke privilege, DataDictionary.addRemovePermissionsDescriptor expects it's callers to set the permission descriptor's uuid so that DependencyManager can be invoked by addRemovePermissionsDescriptor to send REVOKE_PRIVILEGE action to permission descriptor's dependents(sending of REVOKE_PRIVILEGE work has not been finished yet. This patch is in preparation of that work). In order to set the uuid, the callers have to goto system tables to find the uuid and then set the permission descriptor's uuid. It will be less error prone if DataDictionary.addRemovePermissionsDescriptor did the setting of uuid of permission descriptor, rather than having every caller set the uuid correctly. DataDictionary.addRemovePermissionsDescriptor method has to goto the permission system tables anyways and has the uuid information handy and hence it will be more efficient for it to set the uuid of the permission descriptor. This is inline with the patch that was commited some time back so that resetting of the uuid happened in addRemovePermissionsDescriptor method rather than expecting the callers to do that. In order to do this, I have added an abstract method to PermissionsCatalogRowFactory called setUUIDOfThePassedDescriptor. This method will set the uuid of the passed permission descriptor to same value as the row corresponding to the permission system table which is also passed as a parameter. This method will be called by DataDictionary.addRemovePermissionsDescriptor. I have run derbyall suite on my Windows XP machine with Sun's jdk14 and there were no new failures. Can someon please review this patch(Derby1330setUUIDinDataDictionaryV8diff.txt) and if no comments, can a commiter please commit this patch? ps There is another patch pending on this JIRA entry(Derby1330MinorCleanupV7diff.txt). Can a commiter please commit that too? > 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.0.0 > Reporter: Mamta A. Satoor > Assigned To: Mamta A. Satoor > Attachments: AuthorizationModelForDerbySQLStandardAuthorization.html, AuthorizationModelForDerbySQLStandardAuthorizationV2.html, Derby1330MinorCleanupV7diff.txt, Derby1330MinorCleanupV7stat.txt, Derby1330PrivilegeCollectionV2diff.txt, Derby1330PrivilegeCollectionV2stat.txt, Derby1330PrivilegeCollectionV3diff.txt, Derby1330PrivilegeCollectionV3stat.txt, Derby1330setUUIDinDataDictionaryV8diff.txt, Derby1330setUUIDinDataDictionaryV8stat.txt, Derby1330uuidIndexForPermsSystemTablesV4diff.txt, Derby1330uuidIndexForPermsSystemTablesV4stat.txt, Derby1330uuidIndexForPermsSystemTablesV5diff.txt, Derby1330uuidIndexForPermsSystemTablesV5stat.txt, Derby1330uuidIndexForPermsSystemTablesV6diff.txt, Derby1330uuidIndexForPermsSystemTablesV6stat.txt, Derby1330ViewPrivilegeCollectionV1diff.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 order to do that, first we need to collect the privilege requirements for various database objects and store them in SYS.SYSREQUIREDPERM. Once we have this 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. The database object access will succeed only if the user has the necessary privileges. > SYS.SYSTABLEPERMS, SYS.SYSCOLPERMS and SYS.SYSROUTINEPERMS are already populated by Satheesh's work on DERBY-464. But SYS.SYSREQUIREDPERM doesn't have any information in it at this point and hence no runtime privilege checking is getting done at this point. -- 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