db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Deepa Remesh (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-1544) Address remaining upgrade task(s) to complete full upgrade mechanism for GRANT/REVOKE, specifically with changing database owner name from 'DBA' to authorizationId of user invoking upgrade.
Date Sat, 05 Aug 2006 15:31:14 GMT
    [ http://issues.apache.org/jira/browse/DERBY-1544?page=comments#action_12425967 ] 
            
Deepa Remesh commented on DERBY-1544:
-------------------------------------

Thanks Dan for looking at patch 2. 

1) I agree a better test for this is to try executing of the system routines as a user other
than database owner. This is being tested in lang/grantRevokeDDL.sql which I am planning to
run from the upgrade test. I am trying to do this in DERBY-1521. For now, I have verified
this test passes on an upgraded database with this patch applied. It was failing before. 

2) Create and upgrade use the same basic mechanism to grant permissions to system routines.
upgrade uses the method "createRoutinePermPublicDescriptor" which is the same method used
during database creation. I had to slightly modify this method to allow specifying of an authorization
id for the grantor. This is to allow using the authorization id of user performing upgrade
as the grantor. 

In the upgrade path, I have added a wrapper method which gets the UUID of the five system
routines and calls "createRoutinePermPublicDescriptor" on each of them. In the create path,
there is no wrapper method as we get the UUID when we create the routine and directly call
"createRoutinePermPublicDescriptor" immediately after creation of each routine. 

Though create and upgrade use same basic mechanism, I see there is a slight disconnect after
this patch. I have introduced two lists "sysUtilProceduresWithPublicAccess" and "sysUtilFunctionsWithPublicAccess".
These are used only in upgrade path whereas in create path, we do not use these lists. I can
submit a follow-up patch if it may be better to change the create path to use these lists.







> Address remaining upgrade task(s) to complete full upgrade mechanism for GRANT/REVOKE,
specifically with changing database owner name from 'DBA' to authorizationId of user invoking
upgrade.
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: DERBY-1544
>                 URL: http://issues.apache.org/jira/browse/DERBY-1544
>             Project: Derby
>          Issue Type: Sub-task
>          Components: SQL
>    Affects Versions: 10.2.0.0
>         Environment: generic
>            Reporter: Satheesh Bandaram
>         Assigned To: Deepa Remesh
>             Fix For: 10.2.0.0
>
>         Attachments: d1544-patch1-draft.diff, d1544-patch1-v1.diff, d1544-patch1-v1.status,
d1544-patch2-v1.diff, d1544-patch2-v1.status, d1544-patch2-v2.diff
>
>
> Upgrading a database from 10.1 to 10.2 should automatically change database owner, recorded
as owner of system schemas in sysschemas, from pseudo user 'DBA' to authorizationID of the
user attempting upgrade. 
> Another upgrade change I am thinking about is to grant execute privilege to 5 system
routines that by default have execute privilege to public when a new database is created.
Five system routines, two compress routines and three statistics related routines are given
execute privilege to public when a new 10.2 database is created. This is not done when a 10.1
database is upgraded to 10.2 and probably good to include these privileges during database
upgrade.
>  

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

        

Mime
View raw message