Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <13060689.1198249723041.JavaMail.jira@brutus>
Date: Fri, 21 Dec 2007 07:08:43 -0800 (PST)
From: =?utf-8?Q?=C3=98ystein_Gr=C3=B8vlen_=28JIRA=29?= <jira@apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Commented: (DERBY-3282) Add a mechanism for managing users
 in Derby
In-Reply-To: <12635702.1197907123176.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/DERBY-3282?page=3Dcom.atlassian=
.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12553955 ]=20

=C3=98ystein Gr=C3=B8vlen commented on DERBY-3282:
----------------------------------------

> Rick Hillegas commented on DERBY-3282:
> --------------------------------------
> Thanks for continuing the conversation about this topic,
> =C3=98ystein. Yes indeed, let's step further back!
>=20
> I agree that the definition of a Derby system is not what you might
> want. In practical terms it is something like this: the set of Derby
> resources managed by a single VM relying on a single set of system
> properties and a single master property file. It is not a set of
> Derby databases, which might be what you want. Multiple Derby
> systems could run on a single machine and, in the worst case, a
> given database could drift back and forth between two systems,
> depending on which system touches it first after a reboot.

What you are saying is that a Derby system is basically defined by the
derby.properties file that is read at start-up.  It is not quite clear
to me what are the implications of such a definition, but it seems to
imply that a system is just something that is just defined at
run-time.  If you stop the system and later start a system based on
the same property file, is that the same system or a different system?
I guess that two concurrent Derby instances that have been started
with the same property file, would be viewed as two different systems.
Or maybe it is it two instances of the same system?  As you can tell,
it is still not quite clear to me what a Derby system is.-

It seems like the definition is made from a technical viewpoint more
than from a user's viewpoint since it is defined in the context of
program artifacts and not based on how it is to be used.  I think we
need to establish concepts which reflects the user's need, and not
just are a result of how Derby is implemented.

>=20
> I understand the appeal of moving databases from one location to
> another, maybe even between Derby systems. I think that this is
> particularly appealing for single-user, shrink-wrapped
> applications. However, there are already limitations on this useful
> feature. For instance, important aspects of a database's behavior
> may be governed by the master property file and this does not live
> in the database's directory. In addition, a database is sensitive to
> the version of Derby which created it. You can't move a 10.3
> database into a Derby system which is running 10.2. In order to move
> databases safely, you may also have to move some of the "system"
> context.

I acknowledge that just copying the database will not necessarily give
you the same behavior, and I think that is OK as long as we are
talking about system aspects like the size of the page cache.
However, if there we are taliking about properties that change the way
data may be observed, I think it needs to be stored a the database
level.  This includes user level access.


> Unfortunately, some authentication is already part of this "system"
> context. That is because you need system-wide credentials in order
> to create databases and bring down the "system". It seems awkward to
> me that you technically need one set of credentials in order to
> perform these system tasks and another set of credentials in order
> to perform work in a database. In practice, I seriously doubt that
> there are many (or even any) Derby applications which use different
> credentials for system-wide vs. database-specific tasks. Good
> evidence for this is provided I think by the fact that no production
> user has tripped across DERBY-3271 yet.

I agree, and should I guess, I would think that most use system-wide
credentials because they are easy to work with.  You can just edit the
property file, and should you need users for another database, you can
just copy the file and modify it if needed.  Working with
database-specific users are a more tedious and involves SQL procedures
with long names.  In other words, user data in system.properties is a
way of administer users that can be reused for other databases much
like what I discussed in my previous post.  (One of the points of the
proposal in this JIRA seems to be to restrict this easy manipulation
of user data.)

The recent work on security has created another need for system-level
users in that authentication is used to limit what can be performed at a
system level (create databases, shutdown system).  As far as I can
tell this is mostly relevant to network server configurations, since
this does not prevent a local user from circumventing the security
restrictions by starting his system with another set of configuration
files.  This make me wonder whether it would be better to rather talk
about servers than systems in this context.  The main goal seems to be
to restrict what clients of servers will be able to do.

> In fact, the system-wide credentials which you use to create a
> database MUST BE the very same database-specific credentials which
> you use to do work in the database, at least initially. This is
> because database creation actually involves two authentication
> passes. In the first pass, you authenticate at the system level in
> order to create the system tables on disk. In the second pass, you
> then authenticate (using the same credentials) at the database level
> in order to get a connection to the newly created database. I don't
> believe that this coupling of the two credential schemes is
> documented anywhere. It is an unwritten assumption about the way
> that Derby authentication behaves.
>=20
> I think it would be confusing and awkward to require customers to
> operate two different mechanisms for administering users: one
> mechanism for administering users at the system level and another
> mechanism for administering users at the database level.

I agree that this will be awkward, and what I suggest is that for
those who want to do administration at system level, we should provide
a tool that do the database level administration for them.  E.g., if
you add a user at system-level, the tool should make sure this user is
added to all the databases the user should have access to.

>=20
> For the record, I don't have any quarrel with the syntax described
> in DERBY-866. I do have reservations about the database-specific
> scope of the syntax and about the requirement that system-wide
> credentials be stored in the master property file.

I think the database-specific scope is what makes it easy to
understand and use.

I am all for a better way of administering system-wide data, but I
think that can be solved separately from DERBY-866.


> 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 seem=
s appropriate for testing purposes, but has problems in a production settin=
g. DERBY-866 describes part of a new mechanism for managing users. DERBY-86=
6 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, w=
e have the opportunity to think through the complete experience of user man=
agement. Here are my initial thoughts:
> 1) This mechanism is mutually exclusive with the currently supported sett=
ings of the derby.authentication.provider property.
> 2) There should be a super user who has the power to create, view, and dr=
op 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 user=
names can connect to their databases. DBOs should also have the power to st=
ate 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 wan=
t.
> 6) No password needed for this mechanism should be stored in plaintext an=
ywhere on the system.

--=20
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.