[
https://issues.apache.org/jira/browse/DERBY-3282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12553974
]
Rick Hillegas commented on DERBY-3282:
--------------------------------------
I agree that "network server" is often the meaning of "system".
The Developer's Guide, in a section called "Derby system", has this to say:
"A Derby database exists within a system.
"A Derby system is a single instance of the Derby database engine and the
environment in which it runs. It consists of a system directory, zero or more
databases, and a system-wide configuration. The system directory contains any
persistent system-wide configuration parameters, or properties, specific to
that system in a properties file called derby.properties. This file is not
automatically created; you must create it yourself.
"The Derby system is not persistent; you must specify the location of the
system directory at every startup."
I think this definition could easily mislead and confuse people. For instance,
after reading this description, you could come away with the idea that
databases live inside systems, when in fact they can join and leave systems in
non-deterministic ways. The wording around persistence is also confusing to me.
However, this may very well be the most complete attempt to date to describe
what a Derby system is.
Here is an attempt to list the behaviors which are managed at the "system"
level:
1) Network management, including
a) legal sockets
b) DRDA configuration
c) network encryption
2) Safety and security management, including
a) Server and engine shutdown.
b) Database creation.
c) System-wide authentication.
d) Jar files that are eligible for use by all databases.
e) Java security policy
f) Protection against sharing a database between two systems
(derby.database.forceDatabaseLock property
g) Durability (derby.system.durability)
3) Info log management
4) Global defaults for a lot of database-specific behaviors
>From this list I would say that network and safety management are big concerns
>of the "system". If you consider that (1a) and (1c) have implications for
>safety--as do many of the defaults swept up in (4)--it seems to me that one of
>the big behaviors of the "system" is to configure a security domain.
> Add a mechanism for managing users in Derby
> -------------------------------------------
>
> Key: DERBY-3282
> URL: https://issues.apache.org/jira/browse/DERBY-3282
> Project: Derby
> Issue Type: Improvement
> Components: Security
> Reporter: Rick Hillegas
>
> Currently, managing users in Derby is awkward. The BUILTIN mechanism seems
> appropriate for testing purposes, but has problems in a production setting.
> DERBY-866 describes part of a new mechanism for managing users. DERBY-866 may
> be part of the right solution--or it may not be. I think it would be
> worthwhile to step back from this issue and first describe at a high level
> what the customer experience should be. By introducing a new mechanism, we
> have the opportunity to think through the complete experience of user
> management. Here are my initial thoughts:
> 1) This mechanism is mutually exclusive with the currently supported settings
> of the derby.authentication.provider property.
> 2) There should be a super user who has the power to create, view, and drop
> users, including database owners. The design should let this super user
> delegate these powers to other users.
> 3) In the new mechanism it is sufficient that user credentials are
> system-wide.
> 4) Database owners should nevertheless have the power to state which
> usernames can connect to their databases. DBOs should also have the power to
> state who can shut down their databases. This mechanism should be extensible
> to managing other database-specific powers which fall outside the SQL spec.
> The design should let the DBO delegate these powers to other users.
> 5) Users should be able to change their own credentials whenever they want.
> 6) No password needed for this mechanism should be stored in plaintext
> anywhere on the system.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
