db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Satheesh Bandaram <banda...@gmail.com>
Subject Re: Grant/revoke dual mode - is derby.database.sqlAuthorization needed?
Date Thu, 27 Jul 2006 18:30:07 GMT
Daniel John Debrunner wrote:

>Do we really need such a property to be part of the public api, it just
>makes Derby that little bit harder to use.
>
>Why not base the switching of the mode on the first successful execution
>of a GRANT statement?
>
>I also dislike the two modes, and am stil looking at ways to avoid it.
>  
>
It is a worthy cause... if you can find an appropriate way to achieve
this. We did talk about switching the mode during first execution of a
GRANT statement and was rejected before. See this thread and several others:

http://www.nabble.com/Re%3A-Grant-and-Revoke%2C-Part-I-...-DERBY-464...-p2410538.html

This is because of several reasons...

   1. We all agreed switching from Derby authorization to SQL
      authorizaton mode would be visible to applications or users and
      could break existing applications or usages. Especially switching
      automatically could and would cause confusion.
   2. Can any user switch the mode  triggered internally or only
      database owner's GRANT statement would switch the mode? How do you
      account for "accidental" switching of the mode when their real
      "intent" is not to switch? Derby doesn't support switching mode
      from SQL authorization back to Derby authorization mode.
   3. Another issue is lack of system privileges and how it impacts
      object privileges at the moment. There are several severe
      restrictions imposed on SQL authorization mode and users adopting
      to SQL authorization should be sufficiently be warned (or even
      prevented a little) until system privileges are done. Automatic
      switching might get more users into something they may not want.
   4. Many applications are likely to see differences between Derby
      authorization and SQL authorization anyway. Why hide it?
   5. Getting this design past Kathey would not be worth the effort :)
      Seriously, 'Existing Application Impact' flags everywhere!

I had originally suggested keeping a flag at database create time with
current default being Derby authorization for now and switching to SQL
authorization mode in a phased manor as system privileges are later
added. This scheme would have eventually allowed us to drop support for
creating new databases in Derby authorization mode less painfully, I
think. But this current scheme exposes public properties and removing
them might be harder, while it does allow easier switching in the short
term.

Satheesh


Mime
View raw message