[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 us
[ http://issues.apache.org/jira/browse/DERBY-1544?page=comments#action_12423717 ] Satheesh Bandaram commented on DERBY-1544: -- Changes to update database owner is already present in Derby upgrade process it seems there is a defect that is either not committing this transaction during upgrade or starting transaction wrongly. Stepping through the code sometime ago, noticed upgrade does invoke this internal mechanism to update 'DBA' as the owner of system schemas to authorizationID of the invoker of upgrade, but probably because of wrong internal transaction semantics, the change doesn't seem to get committed. For the second part of the sub-task, full upgrade needs to add 5 routine perm descriptors that allow GRANTing of EXECUTE privilege to 5 system routines that by default have execute access. This code needs to be added, much like code that adds 5 system routine permission descriptors during a NEW database creation. > 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 > Fix For: 10.2.0.0 > > > 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
[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 us
[ http://issues.apache.org/jira/browse/DERBY-1544?page=comments#action_12425767 ] Deepa Remesh commented on DERBY-1544: - Ran derbyall with 'd1544-patch2-v1.diff' using Sun jdk1.4.2 on Windows XP. No new failures. patch 1 and patch 2 are ready for review/commit. However, the files in patch 1 and patch 2 conflict with each other. So only one of these patches can be committed. They are independent patches and so any of these patches can be committed first. Later, I can sync up and upload an updated patch for the remaining part. Feedback on both patches appreciated. > 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 > > > 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
[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 us
[ http://issues.apache.org/jira/browse/DERBY-1544?page=comments#action_12425848 ] Daniel John Debrunner commented on DERBY-1544: -- Patch d1544-patch1-v1.diff committed revision 428872 - Thanks Deepa > 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 > > > 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
[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 us
[ http://issues.apache.org/jira/browse/DERBY-1544?page=comments#action_12425929 ] Daniel John Debrunner commented on DERBY-1544: -- I'll commit the patch but I think a better test of if the routines have been granted permission by public to execute would be to execute them by one or more users who is not the database owner. This is then testing the intended functionality rather than a side effect. > 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
[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 us
[ http://issues.apache.org/jira/browse/DERBY-1544?page=comments#action_12425930 ] Daniel John Debrunner commented on DERBY-1544: -- one question before I commit the change, the initial comments indicates that granting the execute permission to these five routines was done for create but not for upgrade. This change is addressing upgrade but seems to be adding new code. Is the code to grant permission for these routines shared between create and upgrade, or are there two separate mechanisms.? for instance, I only see the method grantPublicAccessToSystemRoutines being called from doFullUpgrade. How are these permissions granted at create database time? > 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
[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 us
[ 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
[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 us
[ http://issues.apache.org/jira/browse/DERBY-1544?page=comments#action_12425968 ] Daniel John Debrunner commented on DERBY-1544: -- Thanks for the follow up, if there are two lists for the same set of information thenit is pretty much guaranteed they will get out of sync leading to bugs. If a single list is possible that should be done. > 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
[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 us
[ http://issues.apache.org/jira/browse/DERBY-1544?page=comments#action_12425981 ] Deepa Remesh commented on DERBY-1544: - The lists are used only in upgrade path - one for functions and other for procedures. The create path is directly calling the method after creation of each routine. > 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
