[
https://issues.apache.org/jira/browse/DERBY-3200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12626980#action_12626980
]
Kim Haase commented on DERBY-3200:
----------------------------------
Thanks again, Dag! I seem to be always missing something. What I am going to do
is commit what I have so far and then make the changes, so that the diffs files
will not be so unwieldy and the changes will be easier to see. Then I will make
your fixes.
Yes, the reason there are two client programs and only one embedded is
arbitrary at this point. At some point during my work on DERBY-1823 I think the
programs were written in such a way that they only worked the way I had them,
but that is no longer the case. I combined the two client examples into one and
it worked fine. I split the embedded example into two and that also worked
fine. I should say that we just want to show users that they can do it either
way.
I also realize that it may be confusing to point to the section on SQL
authorization in the topics that have the non-SQL-authorization examples. I'll
pull that out and leave it only in the SQL authorization examples.
I am not sure what you mean by "levels of authorization" -- full access and
read only access? The topics in which the first (non-SQL-auth) examples are
nested talk about setting system properties and database properties and also
about what the full-access and read-only-access authorizations mean. It would
be useful to add pointers to the documentation on properties there, but I'll
save that for DERBY-2389.
I also noticed a comment from Francois on DERBY-1823 (about where to point to
in the Getting Started guide) that I missed before, so I'll make that fix too.
> 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, AuthExampleClient1.java,
> AuthExampleClient2.java, AuthExampleClient2.java, AuthExampleClient2.java,
> AuthExampleClient2.java, AuthExampleClientSQLAuth1.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,
> AuthExampleClientSQLAuth2.java, AuthExampleEmbedded-dhw.java,
> AuthExampleEmbedded.java, AuthExampleEmbedded.java, AuthExampleEmbedded.java,
> AuthExampleEmbedded.java, AuthExampleEmbedded_dhw.java,
> AuthExampleEmbeddedSQLAuth.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.
