[ http://issues.apache.org/jira/browse/DERBY-464?page=comments#action_12370303 ]
Daniel John Debrunner commented on DERBY-464: --------------------------------------------- Thanks for adding the table of system routines in the functional spec. One question on that, in the intro to the table it says - " For instance a user needs to have SELECT privilege on a table to be able to call SYSCS_COMPRESS_TABLE" but that privilege is not reflected in the last column of the table for the compress routines, is it required or not? I wonder if it would be better to be general in the intro rather than an "for instance", e.g. say "additional privileges required are listed in the 'Other privileges needed' column". I think it would be good to be precise & consistent and use the term "PUBLIC" rather than "everyone", might lead to consistency in the user documentation which would be a good thing! > 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: GrantRevokePartII.stat, GrantRevokePartII.txt, > GrantRevokePartII.txt, changeDescriptionPartII, grantRevoke.patch.Dec5, > grantRevoke.stat.Dec5, grantRevokeSpec.html, grantRevokeSpec_v2.html > > 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. -- 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
