db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Francois Orsini (JIRA)" <derby-...@db.apache.org>
Subject [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 configurations.
Date Thu, 27 Oct 2005 00:07:55 GMT
    [ 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)

- The notion of users defined at the system level is NOT just for Derby's built-in authentication
scheme - it is there so that we can better link and integrate users from an outside realm
than Derby's one - Sysusers would be a great start and I would hope to use VTI internally
to materialize (known) users for a particular instance of Derby whether the built-in authentication
scheme is used or not..and I agree that Derby should not care as far as how the user has been
authenticated.

- Most database systems out there have DDL to define users managed by the RDBMS, we don't
have this at the moment - some are using a syntax such as:

    - Grant Connet to username Identified by xyz;
or
    - Create User username Identified by xyz;

as well as DDL for altering users.

- Introduce a rea and internal notion of a User object (descriptor) in Derby - there is none
today


Now, this could be done as part of this charter or not (separate JIRA) but there would be
dependencies at least how a user is instantiated internally (see my last point) and the grant/revoke
implementation at the user descriptor level.

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


Mime
View raw message