[
https://issues.apache.org/jira/browse/DERBY-3200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kim Haase updated DERBY-3200:
-----------------------------
Attachment: DERBY-3200-6.zip
DERBY-3200-6.diff
Attaching DERBY-3200-6.diff and DERBY-3200-6.zip.
These revised examples are based on Dag's latest suggestions and example,
including the error-handling and exit strategy. I've added a method that closes
the connection and shuts down the database, which is called if unexpected
errors occur as well as at the end of the programs.
Some offline consultation with Dag has led to another change. Instead of
turning off the security properties at the end of each program, it seems best
to model the behavior we want to see in real-world examples and to leave the
properties set on each database when we exit the program. This has the side
effect of shortening some very long examples.
The only drawback is that the documentation of how to turn off Derby properties
is spotty -- these examples were the main illustration of it, I think. Setting
a property value to null in effect restores the built-in default setting for
that property. This information needs to be added to the description of Derby
properties in the Tuning Guide, probably in the topic "Derby properties"
(http://db.apache.org/derby/docs/dev/tuning/ctunproper22250.html). The behavior
for turning off user settings is slightly different and is documented in
several places; it's the general case that seems to be missing. I will create a
JIRA issue for this.
New versions of sample programs to follow.
> Developer's Guide: Add examples showing use of SQL authorization with user
> authentication
> -----------------------------------------------------------------------------------------
>
> Key: DERBY-3200
> URL: https://issues.apache.org/jira/browse/DERBY-3200
> Project: Derby
> Issue Type: Improvement
> Components: Documentation
> Reporter: Kim Haase
> Assignee: Kim Haase
> Priority: Minor
> Attachments: auth2.log, AuthExampleClient1.java,
> AuthExampleClient1.java, AuthExampleClient1.java, AuthExampleClient2.java,
> AuthExampleClient2.java, AuthExampleClient2.java,
> AuthExampleClientSQLAuth1.java, AuthExampleClientSQLAuth1.java,
> AuthExampleClientSQLAuth1.java, AuthExampleClientSQLAuth1.java,
> AuthExampleClientSQLAuth1.java, AuthExampleClientSQLAuth1.java,
> AuthExampleClientSQLAuth1.java, AuthExampleClientSQLAuth2.java,
> AuthExampleClientSQLAuth2.java, AuthExampleClientSQLAuth2.java,
> AuthExampleClientSQLAuth2.java, AuthExampleClientSQLAuth2.java,
> AuthExampleClientSQLAuth2.java, AuthExampleClientSQLAuth2.java,
> AuthExampleEmbedded-dhw.java, AuthExampleEmbedded.java,
> AuthExampleEmbedded.java, AuthExampleEmbedded.java,
> AuthExampleEmbedded_dhw.java, AuthExampleEmbeddedSQLAuth.java,
> AuthExampleEmbeddedSQLAuth.java, AuthExampleEmbeddedSQLAuth.java,
> AuthExampleEmbeddedSQLAuth.java, AuthExampleEmbeddedSQLAuth.java,
> AuthExampleEmbeddedSQLAuth.java.dhw, DERBY-3200-2.diff, DERBY-3200-2.zip,
> DERBY-3200-3.diff, DERBY-3200-3.zip, DERBY-3200-4.diff, DERBY-3200-4.zip,
> DERBY-3200-5.diff, DERBY-3200-5.zip, DERBY-3200-6.diff, DERBY-3200-6.zip,
> DERBY-3200.diff, DERBY-3200.stat, DERBY-3200.zip,
> rdevcsecuresqlauthembeddedex.dita, sqlauthclient.txt,
> sqlauthclientshutdown.txt, sqlauthembedded.txt, sqlauthembedded.txt
>
>
> This is the followup to DERBY-1823 that Francois Orsini suggested.
> I've been experimenting and reading the Developer's Guide section on SQL
> authorization (User authorizations, cdevcsecure36595).
> It appears that the only use of SQL authorization mode is to restrict user
> access, not to expand it.
> For example, if you set the default connection mode to noAccess, a user with
> fullAccess can't grant any privileges to a user with noAccess. And presumably
> if the default connection mode is readOnlyAccess, a user with fullAccess
> can't grant any privileges beyond SELECT, which the user has anyway.
> Only if the default connection mode is fullAccess is SQL authorization mode
> meaningful. That means that a fullAccess user can use GRANT to restrict
> another user's privileges on a particular database that the user owns.
> I'm running into a problem at the end, though. At the beginning of the
> program, as nobody in particular, I was able to create several users, some of
> them with full access. But at the end of the program, it seems that even a
> user with full access isn't allowed to turn off those database properties:
> Message: User 'MARY' does not have execute permission on PROCEDURE
> 'SYSCS_UTIL'.'SYSCS_SET_DATABASE_PROPERTY'.
> This seems a bit extreme. I know that with SQL authorization on, "the ability
> to read from or write to database objects is further restricted to the owner
> of the database objects." But the ability to execute built-in system
> procedures? Can I log in as SYSCS_UTIL? How?
> I realize that having access to SYSCS_SET_DATABASE_PROPERTY would allow me to
> in effect delete myself -- but that's essentially what I do at the end of the
> program that sets derby.connection.requireAuthentication but not
> derby.database.sqlAuthorization.
> The documentation does say that once you have turned on SQL authorization,
> you can't turn it off. But it doesn't say that you can't turn anything else
> off, either!
> I'll attach the program I've been using. Most of the stacktraces are
> expected, but I'm stumped by that last one.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
