db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Francois Orsini <francois.ors...@gmail.com>
Subject 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 configurations.
Date Thu, 27 Oct 2005 02:22:41 GMT
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 Grant&Revoke 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)


On 10/26/05, Daniel John Debrunner <djd@debrunners.com> 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 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.

View raw message