Re: [jira] Commented: (DERBY-464) Enhance Derby by adding grant/revoke support. Grant/Revoke provide finner level of privileges than currently provided by Derby that is especially useful in network co
Daniel John Debrunner (JIRA) wrote: [ http://issues.apache.org/jira/browse/DERBY-464?page=comments#action_12423202 ] Daniel John Debrunner commented on DERBY-464: - I would say one definition of sub-task is that the main task is not complete until all of the sub-tasks are. Though I think sometimes sub-tasks are added when a better choice would be to add separate tasks. And the situation is not helped by Jira not allowing sub-tasks to moved once created. Have I missed something, or can you use the 'Move this sub-task' to do that? I haven't tried it, but it seems to be possible to change the parent task. -- Kristian [ snip ]
Re: [jira] Commented: (DERBY-464) Enhance Derby by adding grant/revoke support. Grant/Revoke provide finner level of privileges than currently provided by Derby that is especially useful in network co
Kristian Waagan wrote: Daniel John Debrunner (JIRA) wrote: [ http://issues.apache.org/jira/browse/DERBY-464?page=comments#action_12423202 ] Daniel John Debrunner commented on DERBY-464: - I would say one definition of sub-task is that the main task is not complete until all of the sub-tasks are. Though I think sometimes sub-tasks are added when a better choice would be to add separate tasks. And the situation is not helped by Jira not allowing sub-tasks to moved once created. Have I missed something, or can you use the 'Move this sub-task' to do that? I haven't tried it, but it seems to be possible to change the parent task. I must have missed that, I know I ran into problems when I wanted to change the type of a sub-task to be its own issue. I didn't think about changing the parent to a different (new) parent. Thanks, Dan.
Re: [jira] Commented: (DERBY-464) Enhance Derby by adding grant/revoke support. Grant/Revoke provide finner level of privileges than currently provided by Derby that is especially useful in network co
Yip Ng (JIRA) wrote: My name is Yip Ng and I would like to contribute to the Apache Derby project. Welcome to the project Yip. I just tried to make the information for new devevlopers easier to navigate on the wiki, at http://wiki.apache.org/db-derby/DerbyDev I'd appreciate any feedback on it. [grant/revoke tests bugs snipped] It would be great if you could add these bugs as Jira issues separate to DERBY-464 and link them to DERBY-464. http://db.apache.org/derby/DerbyBugGuidelines.html Thanks, Dan.
Re: [jira] Commented: (DERBY-464) Enhance Derby by adding grant/revoke support. Grant/Revoke provide finner level of privileges than currently provided by Derby that is especially useful in network co
Thanks Dan for the informative links. I'll definitely take a look at them to start my Derby journey. =) I opened DERBY-1538 to track the issue I have found but since I don't have developer access to JIRA, I can't link it to DERBY-464... --- Daniel John Debrunner [EMAIL PROTECTED] wrote: Yip Ng (JIRA) wrote: My name is Yip Ng and I would like to contribute to the Apache Derby project. Welcome to the project Yip. I just tried to make the information for new devevlopers easier to navigate on the wiki, at http://wiki.apache.org/db-derby/DerbyDev I'd appreciate any feedback on it. [grant/revoke tests bugs snipped] It would be great if you could add these bugs as Jira issues separate to DERBY-464 and link them to DERBY-464. http://db.apache.org/derby/DerbyBugGuidelines.html Thanks, Dan. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: [jira] Commented: (DERBY-464) Enhance Derby by adding grant/revoke support. Grant/Revoke provide finner level of privileges than currently provided by Derby that is especially useful in network co
Satheesh Bandaram (JIRA) wrote: All implement check() interface that is used to invoke permission checking for that access descriptor. Access descriptors already know what they need to check for and are passed current user authorizationId. Since g/r is a language issue, it seems like the check() method should take the LCC and not the transaction controller. Then the authorization id would be available in the LCC and not have the potential to be different. Or can it be different, again comments needed here. The equals() method is used to check if an access descriptor is already created for the specific access. For example, a query may have multiple references to same table. No need to create multiple access descriptors for the same table for the same kind of access. This becomes more important as each and every column referenced may try to add an access descriptor for the table in question. I will add these details to the design part of the spec. And to the java code, right? Dan.
Re: [jira] Commented: (DERBY-464) Enhance Derby by adding grant/revoke support. Grant/Revoke provide finner level of privileges than currently provided by Derby that is especially useful in network co
OK... I will see if check() method interface can be changed.. Satheesh Daniel John Debrunner wrote: Satheesh Bandaram (JIRA) wrote: All implement check() interface that is used to invoke permission checking for that access descriptor. Access descriptors already know what they need to check for and are passed current user authorizationId. Since g/r is a language issue, it seems like the check() method should take the LCC and not the transaction controller. Then the authorization id would be available in the LCC and not have the potential to be different. Or can it be different, again comments needed here. The equals() method is used to check if an access descriptor is already created for the specific access. For example, a query may have multiple references to same table. No need to create multiple access descriptors for the same table for the same kind of access. This becomes more important as each and every column referenced may try to add an access descriptor for the table in question. I will add these details to the design part of the spec. And to the java code, right? Dan.
Re: [jira] Commented: (DERBY-464) Enhance Derby by adding grant/revoke support. Grant/Revoke provide finner level of privileges than currently provided by Derby that is especially useful in network co
Hi Francois, I will update functional specification with system table schema. I will also add a high level design section there with some details. I am little pressed for time right now, but will get this out next week. (happens to be my off week, but open source world never sleeps, right?) Satheesh Francois Orsini wrote: Hi Satheesh, I'm reviewing the part I changes you checked-in - there is a lot of changes and it is somewhat tedious to understand some of the decisions that have been made at the implementation level - not saying anything is wrong - it is just hard to follow certain paths without a minimum of high-level technical details about the implementation (i.e. design specs) and mostly because of the amount of changes - there are classes without headers, which makes it difficult to understand the purpose of a class - sure, one can always spend a long time trying to understand things but I think for patches with such amount of changes, some high-level design details would be appreciated by the reviewers...I know you intended to post details about the system catalogs but right now one has to review the changes without a lot of details besides the functional specs...a 1-2 pager high-level implementation details would not just help reviewers to do a better appreciation of the changes but also incentivize more reviewers to look at the changes... Btw, these changes cross a few of the Derby subsystems and am hoping someone can review the query tree and nodes generation (compiler) stuffs... Thanks, --francois On 12/11/05, Satheesh Bandaram (JIRA) derby-dev@db.apache.org wrote: [ http://issues.apache.org/jira/browse/DERBY-464?page=comments#action_12360186 ] Satheesh Bandaram commented on DERBY-464: - I have submitted Grant and Revoke, Part I to trunk. Let me know if anyone would like to join developing remaining parts. It is possible to coordinate development using a Wiki. This Phase I implements: * Grant/Revoke DDL parsing and execution * Addition of several new system tables to hold the system metadata. I will update my spec to include detailed schema for new system tables, so that they can be included in 10.2 documentation. *Enhancing the syntax for routine creation to include external-security clause *Very simple tests to cover only the DDL. I would be expanding on the testing in the later submissions, including a JUnit test suite. * Grant/Revoke DDL is only supported if derby.database.defaultConnectionMode property is set to 'sqlStandard'. Pending items from Phase I: 1. dblook needs to be enhanced to emit DDL for grant statements. 2. Enhanced JUnit based test suite with many more tests. 3. Some implementation improvements possible with the current patch. It should be possible to combine several new nodes being added, to reduce number of nodes and hence foot print. Also, the patch adds a Java object to new system tables. While Derby already has some java objects in its system tables, I think, we should discourage adding new java objects to catalogs. Since Java objects can't be used in SQL easily, this makes metadata harder to use. I will explore rewriting SYSCOLPERMS and SYSREQUIREDPERM to not use FormattableBitSet type. This can be done by having multiple entries in these catalogs for each column referenced. 4. Updating specification to include schema for new system tables. 5. Need to change how property defaultConnectionMode is set and/or used. 6. Enhance system tables to store external security clause specification. I am also working on Grant and Revoke, Phase II. This will implement permission checking for DML statement. Hopefully I will have something to submit by end of January to complete Phase I and Phase II. Also need to support upgrade and migration of legacy databases and update JDBC metadata. Let me know if I missed anything else. Enhance Derby by adding grant/revoke support. Grant/Revoke provide finner level of privileges than currently provided by Derby that is especially useful in network configurations. --- Key: DERBY-464 URL: http://issues.apache.org/jira/browse/DERBY-464 Project: Derby Type: New Feature Components: SQL Versions: 10.0.2.1, 10.1.1.0, 10.2.0.0 Environment: generic Reporter: Satheesh Bandaram Assignee: Satheesh Bandaram Attachments: grant.html, grantRevoke.patch.Dec5, grantRevoke.stat.Dec5 Derby currently provides a very simple permissions scheme, which is quite suitable for an embedded database system. End users of embedded Derby do not see Derby directly; they talk to a application that embeds Derby. So Derby left most of the access control work to the application. Under this scheme, Derby limits access on a per database or per
Re: [jira] Commented: (DERBY-464) Enhance Derby by adding grant/revoke support. Grant/Revoke provide finner level of privileges than currently provided by Derby that is especially useful in network co
Thanks Satheesh - much appreciated ;)On 12/16/05, Satheesh Bandaram [EMAIL PROTECTED] wrote: Hi Francois, I will update functional specification with system table schema. I will also add a high level design section there with some details. I am little pressed for time right now, but will get this out next week. (happens to be my off week, but open source world never sleeps, right?) Satheesh Francois Orsini wrote: Hi Satheesh, I'm reviewing the part I changes you checked-in - there is a lot of changes and it is somewhat tedious to understand some of the decisions that have been made at the implementation level - not saying anything is wrong - it is just hard to follow certain paths without a minimum of high-level technical details about the implementation (i.e. design specs) and mostly because of the amount of changes - there are classes without headers, which makes it difficult to understand the purpose of a class - sure, one can always spend a long time trying to understand things but I think for patches with such amount of changes, some high-level design details would be appreciated by the reviewers...I know you intended to post details about the system catalogs but right now one has to review the changes without a lot of details besides the functional specs...a 1-2 pager high-level implementation details would not just help reviewers to do a better appreciation of the changes but also incentivize more reviewers to look at the changes... Btw, these changes cross a few of the Derby subsystems and am hoping someone can review the query tree and nodes generation (compiler) stuffs... Thanks, --francois On 12/11/05, Satheesh Bandaram (JIRA) derby-dev@db.apache.org wrote: [ http://issues.apache.org/jira/browse/DERBY-464?page=comments#action_12360186 ] Satheesh Bandaram commented on DERBY-464: - I have submitted Grant and Revoke, Part I to trunk. Let me know if anyone would like to join developing remaining parts. It is possible to coordinate development using a Wiki. This Phase I implements: * Grant/Revoke DDL parsing and execution * Addition of several new system tables to hold the system metadata. I will update my spec to include detailed schema for new system tables, so that they can be included in 10.2 documentation. *Enhancing the syntax for routine creation to include external-security clause *Very simple tests to cover only the DDL. I would be expanding on the testing in the later submissions, including a JUnit test suite. * Grant/Revoke DDL is only supported if derby.database.defaultConnectionMode property is set to 'sqlStandard'. Pending items from Phase I: 1. dblook needs to be enhanced to emit DDL for grant statements. 2. Enhanced JUnit based test suite with many more tests. 3. Some implementation improvements possible with the current patch. It should be possible to combine several new nodes being added, to reduce number of nodes and hence foot print. Also, the patch adds a Java object to new system tables. While Derby already has some java objects in its system tables, I think, we should discourage adding new java objects to catalogs. Since Java objects can't be used in SQL easily, this makes metadata harder to use. I will explore rewriting SYSCOLPERMS and SYSREQUIREDPERM to not use FormattableBitSet type. This can be done by having multiple entries in these catalogs for each column referenced. 4. Updating specification to include schema for new system tables. 5. Need to change how property defaultConnectionMode is set and/or used. 6. Enhance system tables to store external security clause specification. I am also working on Grant and Revoke, Phase II. This will implement permission checking for DML statement. Hopefully I will have something to submit by end of January to complete Phase I and Phase II. Also need to support upgrade and migration of legacy databases and update JDBC metadata. Let me know if I missed anything else. Enhance Derby by adding grant/revoke support. Grant/Revoke provide finner level of privileges than currently provided by Derby that is especially useful in network configurations. --- Key: DERBY-464 URL: http://issues.apache.org/jira/browse/DERBY-464 Project: Derby Type: New Feature Components: SQL Versions: 10.0.2.1, 10.1.1.0, 10.2.0.0 Environment: generic Reporter: Satheesh Bandaram Assignee: Satheesh Bandaram Attachments: grant.html, grantRevoke.patch.Dec5, grantRevoke.stat.Dec5 Derby currently provides a very simple permissions scheme, which is quite suitable for an embedded database system. End users of embedded Derby do not see Derby directly; they talk to a application that embeds Derby. So Derby left most of the
Re: [jira] Commented: (DERBY-464) Enhance Derby by adding grant/revoke support. Grant/Revoke provide finner level of privileges than currently provided by Derby that is especially useful in network co
Hi Satheesh, I'm reviewing the part I changes you checked-in - there is a lot of changes and it is somewhat tedious to understand some of the decisions that have been made at the implementation level - not saying anything is wrong - it is just hard to follow certain paths without a minimum of high-level technical details about the implementation (i.e. design specs) and mostly because of the amount of changes - there are classes without headers, which makes it difficult to understand the purpose of a class - sure, one can always spend a long time trying to understand things but I think for patches with such amount of changes, some high-level design details would be appreciated by the reviewers...I know you intended to post details about the system catalogs but right now one has to review the changes without a lot of details besides the functional specs...a 1-2 pager high-level implementation details would not just help reviewers to do a better appreciation of the changes but also incentivize more reviewers to look at the changes... Btw, these changes cross a few of the Derby subsystems and am hoping someone can review the query tree and nodes generation (compiler) stuffs... Thanks, --francoisOn 12/11/05, Satheesh Bandaram (JIRA) derby-dev@db.apache.org wrote: [ http://issues.apache.org/jira/browse/DERBY-464?page=comments#action_12360186 ]Satheesh Bandaram commented on DERBY-464: -I have submitted Grant and Revoke, Part I to trunk. Let me know if anyone would like to join developing remaining parts. It is possible to coordinate development using a Wiki.This Phase I implements:* Grant/Revoke DDL parsing and execution* Addition of several new system tables to hold the system metadata. I will update my spec to include detailed schema for new system tables, so that they can be included in 10.2 documentation.*Enhancing the syntax for routine creation to include external-security clause*Very simple tests to cover only the DDL. I would be expanding on the testing in the later submissions, including a JUnit test suite.* Grant/Revoke DDL is only supported if derby.database.defaultConnectionMode property is set to 'sqlStandard'.Pending items from Phase I: 1. dblook needs to be enhanced to emit DDL for grant statements. 2. Enhanced JUnit based test suite with many more tests. 3. Some implementation improvements possible with the current patch. It should be possible to combine several new nodes being added, to reduce number of nodes and hence foot print. Also, the patch adds a Java object to new system tables. While Derby already has some java objects in its system tables, I think, we should discourage adding new java objects to catalogs. Since Java objects can't be used in SQL easily, this makes metadata harder to use. I will explore rewriting SYSCOLPERMS and SYSREQUIREDPERM to not use FormattableBitSet type. This can be done by having multiple entries in these catalogs for each column referenced. 4. Updating specification to include schema for new system tables. 5. Need to change how property defaultConnectionMode is set and/or used. 6. Enhance system tables to store external security clause specification.I am also working on Grant and Revoke, Phase II. This will implement permission checking for DML statement. Hopefully I will have something to submit by end of January to complete Phase I and Phase II.Also need to support upgrade and migration of legacy databases and update JDBC metadata.Let me know if I missed anything else. Enhance Derby by adding grant/revoke support. Grant/Revoke provide finner level of privileges than currently provided by Derby that is especially useful in network configurations. --- Key: DERBY-464URL: http://issues.apache.org/jira/browse/DERBY-464Project: Derby Type: New Feature Components: SQL Versions: 10.0.2.1, 10.1.1.0, 10.2.0.0Environment: generic Reporter: Satheesh Bandaram Assignee: Satheesh BandaramAttachments: grant.html, grantRevoke.patch.Dec5, grantRevoke.stat.Dec5 Derby currently provides a very simple permissions scheme, which is quite suitable for an embedded database system. End users of embedded Derby do not see Derby directly; they talk to a application that embeds Derby. So Derby left most of the access control work to the application. Under this scheme, Derby limits access on a per database or per system basis. A user can be granted full, read-only, or no access. This is less suitable in a general purpose SQL server. When end users or diverse applications can issue SQL commands directly against the database, Derby must provide more precise mechanisms to limit who can do what with the database. I propose to enhance Derby by implementing a subset of grant/revoke capabilities as specified by the SQL standard. I envision this work to involve the following
Re: [jira] Commented: (DERBY-464) Enhance Derby by adding grant/revoke support. Grant/Revoke provide finner level of privileges than currently provided by Derby that is especially useful in network co
Hi, Satheesh. I am still learning the Apache Way, so I wanted to get some clarity on how things are generally done. I know that committers have the merit and trust to commit what they want. I had generally assumed, however, that a large change like this should be posted as a patch for review before being committed. Is the approach that we do an svn diff of the change revision and we can send you comments, and you can make changes in response? Thanks, David Satheesh Bandaram (JIRA) wrote: [ http://issues.apache.org/jira/browse/DERBY-464?page=comments#action_12360186 ] Satheesh Bandaram commented on DERBY-464: - I have submitted Grant and Revoke, Part I to trunk. Let me know if anyone would like to join developing remaining parts. It is possible to coordinate development using a Wiki. This Phase I implements: * Grant/Revoke DDL parsing and execution * Addition of several new system tables to hold the system metadata. I will update my spec to include detailed schema for new system tables, so that they can be included in 10.2 documentation. * Enhancing the syntax for routine creation to include external-security clause * Very simple tests to cover only the DDL. I would be expanding on the testing in the later submissions, including a JUnit test suite. * Grant/Revoke DDL is only supported if derby.database.defaultConnectionMode property is set to 'sqlStandard'. Pending items from Phase I: 1. dblook needs to be enhanced to emit DDL for grant statements. 2. Enhanced JUnit based test suite with many more tests. 3. Some implementation improvements possible with the current patch. It should be possible to combine several new nodes being added, to reduce number of nodes and hence foot print. Also, the patch adds a Java object to new system tables. While Derby already has some java objects in its system tables, I think, we should discourage adding new java objects to catalogs. Since Java objects can't be used in SQL easily, this makes metadata harder to use. I will explore rewriting SYSCOLPERMS and SYSREQUIREDPERM to not use FormattableBitSet type. This can be done by having multiple entries in these catalogs for each column referenced. 4. Updating specification to include schema for new system tables. 5. Need to change how property defaultConnectionMode is set and/or used. 6. Enhance system tables to store external security clause specification. I am also working on Grant and Revoke, Phase II. This will implement permission checking for DML statement. Hopefully I will have something to submit by end of January to complete Phase I and Phase II. Also need to support upgrade and migration of legacy databases and update JDBC metadata. Let me know if I missed anything else. Enhance Derby by adding grant/revoke support. Grant/Revoke provide finner level of privileges than currently provided by Derby that is especially useful in network configurations. --- Key: DERBY-464 URL: http://issues.apache.org/jira/browse/DERBY-464 Project: Derby Type: New Feature Components: SQL Versions: 10.0.2.1, 10.1.1.0, 10.2.0.0 Environment: generic Reporter: Satheesh Bandaram Assignee: Satheesh Bandaram Attachments: grant.html, grantRevoke.patch.Dec5, grantRevoke.stat.Dec5 Derby currently provides a very simple permissions scheme, which is quite suitable for an embedded database system. End users of embedded Derby do not see Derby directly; they talk to a application that embeds Derby. So Derby left most of the access control work to the application. Under this scheme, Derby limits access on a per database or per system basis. A user can be granted full, read-only, or no access. This is less suitable in a general purpose SQL server. When end users or diverse applications can issue SQL commands directly against the database, Derby must provide more precise mechanisms to limit who can do what with the database. I propose to enhance Derby by implementing a subset of grant/revoke capabilities as specified by the SQL standard. I envision this work to involve the following tasks, at least: 1) Develop a specification of what capabilities I would like to add to Derby. 2) Provide a high level implementation scheme. 3) Pursue a staged development plan, with support for DDL added to Derby first. 4) Add support for runtime checking of these privileges. 5) Address migration and upgrade issues from previous releases and from old scheme to newer database. Since I think this is a large task, I would like to invite any interested people to work with me on this large and important enhancement to Derby. begin:vcard fn:David W Van Couvering n:Van Couvering;David W org:Sun Microsystems, Inc.;Database Technology Group
Re: [jira] Commented: (DERBY-464) Enhance Derby by adding grant/revoke support. Grant/Revoke provide finner level of privileges than currently provided by Derby that is especially useful in network co
Hi David, I did post the patch for review... I followed up the post after few days to invite anyone to review again. That time I said I could wait for review comments or submit then address comments. I also said I would submit the patch over the next weekend. Since no one replied that either they want more time or going to review before submission, I submitted the change. http://article.gmane.org/gmane.comp.apache.db.derby.devel/3 http://article.gmane.org/gmane.comp.apache.db.derby.devel/11012 I am willing to address any review comments anyone has. Should I have waited for more time? I wanted to submit the changes over the weekend to minimize any disruptions... Satheesh David W. Van Couvering wrote: Hi, Satheesh. I am still learning the Apache Way, so I wanted to get some clarity on how things are generally done. I know that committers have the merit and trust to commit what they want. I had generally assumed, however, that a large change like this should be posted as a patch for review before being committed. Is the approach that we do an svn diff of the change revision and we can send you comments, and you can make changes in response? Thanks, David Satheesh Bandaram (JIRA) wrote: [ http://issues.apache.org/jira/browse/DERBY-464?page=comments#action_12360186 ] Satheesh Bandaram commented on DERBY-464: - I have submitted Grant and Revoke, Part I to trunk. Let me know if anyone would like to join developing remaining parts. It is possible to coordinate development using a Wiki. This Phase I implements: * Grant/Revoke DDL parsing and execution * Addition of several new system tables to hold the system metadata. I will update my spec to include detailed schema for new system tables, so that they can be included in 10.2 documentation. * Enhancing the syntax for routine creation to include external-security clause * Very simple tests to cover only the DDL. I would be expanding on the testing in the later submissions, including a JUnit test suite. * Grant/Revoke DDL is only supported if derby.database.defaultConnectionMode property is set to 'sqlStandard'. Pending items from Phase I: 1. dblook needs to be enhanced to emit DDL for grant statements. 2. Enhanced JUnit based test suite with many more tests.3. Some implementation improvements possible with the current patch. It should be possible to combine several new nodes being added, to reduce number of nodes and hence foot print. Also, the patch adds a Java object to new system tables. While Derby already has some java objects in its system tables, I think, we should discourage adding new java objects to catalogs. Since Java objects can't be used in SQL easily, this makes metadata harder to use. I will explore rewriting SYSCOLPERMS and SYSREQUIREDPERM to not use FormattableBitSet type. This can be done by having multiple entries in these catalogs for each column referenced. 4. Updating specification to include schema for new system tables. 5. Need to change how property defaultConnectionMode is set and/or used. 6. Enhance system tables to store external security clause specification. I am also working on Grant and Revoke, Phase II. This will implement permission checking for DML statement. Hopefully I will have something to submit by end of January to complete Phase I and Phase II. Also need to support upgrade and migration of legacy databases and update JDBC metadata. Let me know if I missed anything else. Enhance Derby by adding grant/revoke support. Grant/Revoke provide finner level of privileges than currently provided by Derby that is especially useful in network configurations. --- Key: DERBY-464 URL: http://issues.apache.org/jira/browse/DERBY-464 Project: Derby Type: New Feature Components: SQL Versions: 10.0.2.1, 10.1.1.0, 10.2.0.0 Environment: generic Reporter: Satheesh Bandaram Assignee: Satheesh Bandaram Attachments: grant.html, grantRevoke.patch.Dec5, grantRevoke.stat.Dec5 Derby currently provides a very simple permissions scheme, which is quite suitable for an embedded database system. End users of embedded Derby do not see Derby directly; they talk to a application that embeds Derby. So Derby left most of the access control work to the application. Under this scheme, Derby limits access on a per database or per system basis. A user can be granted full, read-only, or no access. This is less suitable in a general purpose SQL server. When end users or diverse applications can issue SQL commands directly against the database, Derby must provide more precise mechanisms to limit who can do what with the database. I propose to enhance Derby by implementing a
Re: [jira] Commented: (DERBY-464) Enhance Derby by adding grant/revoke support. Grant/Revoke provide finner level of privileges than currently provided by Derby that is especially useful in network co
Thanks, Sateesh. Sorry, I missed the request for review comments. No need; I personally am not able at this time to review your changes. I just thought this was the first time we saw these changes. My mistake. David Satheesh Bandaram wrote: Hi David, I did post the patch for review... I followed up the post after few days to invite anyone to review again. That time I said I could wait for review comments or submit then address comments. I also said I would submit the patch over the next weekend. Since no one replied that either they want more time or going to review before submission, I submitted the change. http://article.gmane.org/gmane.comp.apache.db.derby.devel/3 http://article.gmane.org/gmane.comp.apache.db.derby.devel/11012 I am willing to address any review comments anyone has. Should I have waited for more time? I wanted to submit the changes over the weekend to minimize any disruptions... Satheesh David W. Van Couvering wrote: Hi, Satheesh. I am still learning the Apache Way, so I wanted to get some clarity on how things are generally done. I know that committers have the merit and trust to commit what they want. I had generally assumed, however, that a large change like this should be posted as a patch for review before being committed. Is the approach that we do an svn diff of the change revision and we can send you comments, and you can make changes in response? Thanks, David Satheesh Bandaram (JIRA) wrote: [ http://issues.apache.org/jira/browse/DERBY-464?page=comments#action_12360186 ] Satheesh Bandaram commented on DERBY-464: - I have submitted Grant and Revoke, Part I to trunk. Let me know if anyone would like to join developing remaining parts. It is possible to coordinate development using a Wiki. This Phase I implements: * Grant/Revoke DDL parsing and execution * Addition of several new system tables to hold the system metadata. I will update my spec to include detailed schema for new system tables, so that they can be included in 10.2 documentation. * Enhancing the syntax for routine creation to include external-security clause * Very simple tests to cover only the DDL. I would be expanding on the testing in the later submissions, including a JUnit test suite. * Grant/Revoke DDL is only supported if derby.database.defaultConnectionMode property is set to 'sqlStandard'. Pending items from Phase I: 1. dblook needs to be enhanced to emit DDL for grant statements. 2. Enhanced JUnit based test suite with many more tests.3. Some implementation improvements possible with the current patch. It should be possible to combine several new nodes being added, to reduce number of nodes and hence foot print. Also, the patch adds a Java object to new system tables. While Derby already has some java objects in its system tables, I think, we should discourage adding new java objects to catalogs. Since Java objects can't be used in SQL easily, this makes metadata harder to use. I will explore rewriting SYSCOLPERMS and SYSREQUIREDPERM to not use FormattableBitSet type. This can be done by having multiple entries in these catalogs for each column referenced. 4. Updating specification to include schema for new system tables. 5. Need to change how property defaultConnectionMode is set and/or used. 6. Enhance system tables to store external security clause specification. I am also working on Grant and Revoke, Phase II. This will implement permission checking for DML statement. Hopefully I will have something to submit by end of January to complete Phase I and Phase II. Also need to support upgrade and migration of legacy databases and update JDBC metadata. Let me know if I missed anything else. Enhance Derby by adding grant/revoke support. Grant/Revoke provide finner level of privileges than currently provided by Derby that is especially useful in network configurations. --- Key: DERBY-464 URL: http://issues.apache.org/jira/browse/DERBY-464 Project: Derby Type: New Feature Components: SQL Versions: 10.0.2.1, 10.1.1.0, 10.2.0.0 Environment: generic Reporter: Satheesh Bandaram Assignee: Satheesh Bandaram Attachments: grant.html, grantRevoke.patch.Dec5, grantRevoke.stat.Dec5 Derby currently provides a very simple permissions scheme, which is quite suitable for an embedded database system. End users of embedded Derby do not see Derby directly; they talk to a application that embeds Derby. So Derby left most of the access control work to the application. Under this scheme, Derby limits access on a per database or per system basis. A user can be granted full, read-only, or no access. This is less suitable in a general purpose SQL server. When end users or diverse applications can issue SQL commands directly
Re: [jira] Commented: (DERBY-464) Enhance Derby by adding grant/revoke support. Grant/Revoke provide finner level of privileges than currently provided by Derby that is especially useful in network co
Why exactly would we want to strengthen builtin-authentication scheme when all of us agreed it was for simple embedded application use? I am not sure how useful access control is for embedded usages. But I will hold off on any more questions and wait for your proposal. Satheesh Francois Orsini wrote: I'm all for having a homogeneous and unified way to manage (create, drop, alter, etc) users in Derby and specifically for the built-in authentication scheme which is what I was referring to. Today we simply don't have that. More to follow as am starting to feel itchy ;) --francois On 10/26/05, Daniel John Debrunner [EMAIL PROTECTED] wrote: Francois Orsini wrote: Agreed since we always made it clear that users could be defined at the system and/or database level ;) However, even as of today, databases can be dependent on users defined at the system level if you have 'derby.database.propertiesOnly' set to false which is the default I believe ;) What I meant to say is: (and this was in the context of GrantRevoke access to database(s) when users are defined at the system level in my case which I think we'll be the most popular choice - 80/20 rule) Yep, flexibility is good. As long as we continue to support self-contained databases. A system database would be a significant new feature. Of course, I'm unclear on exactly what you are proposing, is it a new authentication scheme or something else? I eagerly await the functional spec/proposal. :-) Dan.
Re: [jira] Commented: (DERBY-464) Enhance Derby by adding grant/revoke support. Grant/Revoke provide finner level of privileges than currently provided by Derby that is especially useful in network co
Derby's Built-in authentication can be used in a client-server mode today along with DRDA's secure transport mechanisms of users' credential across the wire. Originally, we had no cloudscape network driver besides 3rd party ones which were NOT providing secure transport of user credentials across the wire besides using SSL (which encrypts everything not just credentials - overkill if you don't need it) - I don't see why we could not improve the way user passwords are stored at the system level to be as secure as the ones defined at the database level. This is internal afterall - then, I would like to see a unified way of defining users at the database and system level when using built-in authentication - a simple 'CREATE USER' command for instance (and am just taking a quick example) would do it and improve useability at the same time - implementation details (storage) are internal as it is done at the database level...I believe that Derby will be used more and more in a client-server mode, along with built-in authentication way of storing credentials (SHA-1 single-hashed) which is fairly secure already (at the database level) - yes a few bits could be improved but the storage of credentials is actually pretty good at the database level. It does not make sense anymore to have to have 2 ways to define users for a particular authentication scheme which is the built-in database system one. This is exactly in-line as far as why we would implement grant/revoke now since we didn't think we needed it when we implemented the other and simpler scheme via properties back then as we were thinking embedded (which lead us to piggy-back on using java 'properties' to define ACLs as we did for users) Authorization is different than authentication, hence I agree with the second part of your statement. I will post a proposal once am done and the community can comment on it. --francoisOn 10/27/05, Satheesh Bandaram [EMAIL PROTECTED] wrote: Why exactly would we want to strengthen builtin-authentication scheme when all of us agreed it was for simple embedded application use? I am not sure how useful access control is for embedded usages. But I will hold off on any more questions and wait for your proposal. Satheesh Francois Orsini wrote: I'm all for having a homogeneous and unified way to manage (create, drop, alter, etc) users in Derby and specifically for the built-in authentication scheme which is what I was referring to. Today we simply don't have that. More to follow as am starting to feel itchy ;) --francois On 10/26/05, Daniel John Debrunner [EMAIL PROTECTED] wrote: Francois Orsini wrote: Agreed since we always made it clear that users could be defined at the system and/or database level ;) However, even as of today, databases can be dependent on users defined at the system level if you have 'derby.database.propertiesOnly' set to false which is the default I believe ;) What I meant to say is: (and this was in the context of GrantRevoke access to database(s) when users are defined at the system level in my case which I think we'll be the most popular choice - 80/20 rule) Yep, flexibility is good. As long as we continue to support self-contained databases. A system database would be a significant new feature. Of course, I'm unclear on exactly what you are proposing, is it a new authentication scheme or something else? I eagerly await the functional spec/proposal. :-) Dan.
Re: [jira] Commented: (DERBY-464) Enhance Derby by adding grant/revoke support. Grant/Revoke provide finner level of privileges than currently provided by Derby that is especially useful in network co
Francois Orsini (JIRA) wrote: [ http://issues.apache.org/jira/browse/DERBY-464?page=comments#action_12356032 ] Francois Orsini commented on DERBY-464: --- The way I implememted users in Cloudscape originally was done in a Cloudscape running Embedded mindset rather than anything else - in a similar way we what ww have done for permissions via properties - defining users is one thing, authenticating them via various schemes in another - For instance today, users defined at the System level, not database one, do not have their password encrypted for the built-in authentication scheme. I agree that users can be defined outside of Derby but we can't assume all organizations have an LDAP server out there - in fact, a lot if not most of them still don't have one. What I have in mind for Derby defined users is the following: Probably good to move this to a different topic, rather than clutter up the grant/revoke issue. Dan.
Re: [jira] Commented: (DERBY-464) Enhance Derby by adding grant/revoke support. Grant/Revoke provide finner level of privileges than currently provided by Derby that is especially useful in network co
Francois Orsini (JIRA) wrote: [ http://issues.apache.org/jira/browse/DERBY-464?page=comments#action_12356032 ] Francois Orsini commented on DERBY-464: --- The way I implememted users in Cloudscape originally was done in a Cloudscape running Embedded mindset rather than anything else - in a similar way we what ww have done for permissions via properties - defining users is one thing, authenticating them via various schemes in another - For instance today, users defined at the System level, not database one, do not have their password encrypted for the built-in authentication scheme. I agree that users can be defined outside of Derby but we can't assume all organizations have an LDAP server out there - in fact, a lot if not most of them still don't have one. What I have in mind for Derby defined users is the following: - Users should be defined at the System level and added to databases as required (Grant access to a database) That, to my mind would be a bad step. Currently Derby databases are independent of any system, they are self contained. Thus they can be copied anywhere and continue to work. Adding a dependency on a system database just seems wrong. I've often thought that one mistake made in the early days was to have the concept of a system, the single derby.properties, derby.log file, or reading system properties. Dan.
Re: [jira] Commented: (DERBY-464) Enhance Derby by adding grant/revoke support. Grant/Revoke provide finner level of privileges than currently provided by Derby that is especially useful in network co
Agreed since we always made it clear that users could be defined at the system and/or database level ;) However, even as of today, databases can be dependent on users defined at the system level if you have 'derby.database.propertiesOnly' set to false which is the default I believe ;) What I meant to say is: (and this was in the context of GrantRevoke access to database(s) when users are defined at the system level in my case which I think we'll be the most popular choice - 80/20 rule) It's ok to have a user being defined as a legitimate user of a database (sysusers catalog in the database for instance - never meant to remove a notion like that since we allow something similar today) - but on the other hands, one should not have to define users at the database level if they don't want to. Today we can have a user password being encrypted at the database level but not at the system one - hence the motivation for improving this at the system level in the case of Derby's built-in authentication (password-based) - we should not require to have to define users' credentials in every database they can access because we think a database should be independent of the system level (one) - it is great of course but there could be user management useability issues having to manage a user across several databases if one does not plug into a directory service (i.e. LDAP)...User definitions and therefore credentials at the System level are too exposed right now and we know why - user definition at the database level is more secure than at the system level and I believe this should be fixed/addressed (am not a big fan of exposed system properties either and especially when passwords are involved) but this is the path we had decided as you said... I'm just guessing and I may be wrong that most DBA's will either want to define users at the system level _or_ have Derby authenticate against their directory service (users' credentials managed outside then). So yes, we could have a Sysusers (virtual or not) table at the database and system level to define user access for the database or system-wide, as well as providing a more secure storage for encrypted passwords (and especially for the users defined at the system level). This would provide a unified way of storing user credentials for the built-in scheme at least as well as looking at current defined users (i.e. common sysusers interface) --francoisOn 10/26/05, Daniel John Debrunner [EMAIL PROTECTED] wrote: Francois Orsini (JIRA) wrote: [ http://issues.apache.org/jira/browse/DERBY-464?page=comments#action_12356032 ] Francois Orsini commented on DERBY-464: --- The way I implememted users in Cloudscape originally was done in a Cloudscape running Embedded mindset rather than anything else - in a similar way we what ww have done for permissions via properties - defining users is one thing, authenticating them via various schemes in another - For instance today, users defined at the System level, not database one, do not have their password encrypted for the built-in authentication scheme. I agree that users can be defined outside of Derby but we can't assume all organizations have an LDAP server out there - in fact, a lot if not most of them still don't have one. What I have in mind for Derby defined users is the following: - Users should be defined at the System level and added to databases as required (Grant access to a database) That, to my mind would be a bad step. Currently Derby databases areindependent of any system, they are self contained. Thus they can becopied anywhere and continue to work. Adding a dependency on a system database just seems wrong.I've often thought that one mistake made in the early days was to havethe concept of a system, the single derby.properties, derby.log file, orreading system properties. Dan.
