[
https://issues.apache.org/jira/browse/DERBY-5299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rick Hillegas updated DERBY-5299:
---------------------------------
Attachment: 5299_withAuth.sql
5299_setup.sql
Attaching 5299_setup.sql and 5299_withAuth.sql. These scripts demonstrate what
happens when you create a database without enabling
authentication/authorization and then what happens when you enable those
features later on.
To see what happens, run the first script through ij without setting any system
properties. After that, run the second script through ij, setting the following
system properties:
-Dderby.connection.requireAuthentication=true \
-Dderby.authentication.provider=BUILTIN \
-Dderby.user.admin=adminpassword \
-Dderby.user.alice=alicepassword \
-Dderby.user.ruth=ruthpassword \
-Dderby.user.test_dbo=test_dbopassword \
-Dderby.user.app=apppassword \
-Dderby.database.sqlAuthorization=true \
You will see this:
1) In a database created without authentication/authorization and where a user
name is not specified in the connection URL, the default user is APP. The APP
user owns all of the system schemas in the database in addition to owning its
own user schema named APP. The APP user can run all system routines.
2) The second script connects to the database as username APP, supplying a
password. The first thing that this user does is turn on authorization by
setting the database property derby.database.sqlAuthorization to true. For this
setting to take effect, the database must be brought down and back up again.
3) After that, users can't access data in one another's schemas unless they are
granted privilege. In addition, sensitive system functions/procedures can only
be run by the APP user. APP is the database owner.
4) Derby does not provide a way to change the database owner.
This behavior is largely described in the fifth version of the functional spec
attached to DERBY-464. That spec also describes which system routines can be
run by all users and which system routines can only be run by the database
owner. I don't know where in our user documentation we describe how enabling
authorization restricts the running of system routines.
> Document what you should expect to see if you enable
> authentication/authorization on a database which was created without those
> safeguards.
> -------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-5299
> URL: https://issues.apache.org/jira/browse/DERBY-5299
> Project: Derby
> Issue Type: Improvement
> Components: Documentation
> Affects Versions: 10.9.0.0
> Reporter: Rick Hillegas
> Attachments: 5299_setup.sql, 5299_withAuth.sql
>
>
> It is possible to deploy the first version of your Derby-powered application
> without enabling authentication and authorization. In a later version of your
> application, you may want to boost security by enabling these features. It
> would be good to tell users what they should expect when they enable
> authentication/authorization on a legacy database.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
