[
https://issues.apache.org/jira/browse/DERBY-3095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John H. Embretsen updated DERBY-3095:
-------------------------------------
Attachment: d3095.sql
Attaching an example sql script, d3095.sql, which confirms EDAH-TALLY's
understanding of the actual behavior of the SYSCS_UTIL.SYSCS_SET_USER_ACCESS
system procedure.
The script does the following:
- user alice creates a database
- authentication is turned on
- alice defines two username/password pairs, one for herself and one for eve
- alice gives herself and eve full access to the database
- alice sets the default database access to "noAccess" and disconnects
- eve connects and creates a table, then disconnects
- alice tries to revokes eve's access (specifying the username 'eve')
- eve is still in the list of fullAccess users, and is still able to connect
and delete a table
- alice again tries to revoke eve's access, now specifying the username in
uppercase ('EVE')
- eve is no longer in the list of fullAccess users, and is no longer able to
connect
The Dev guide for trunk,
http://db.apache.org/derby/docs/dev/devguide/cdevcsecure24458.html, says:
"When specifying which users are authorized to access the accounting database,
you must list Fred's authorization identifier, FRED (which you can type as
FRED, FREd, or fred, since the system automatically converts it to
all-uppercase)."
So it seems to me that there is a product bug in addition to the documentation
bugs for SYSCS_UTIL.SYSCS_SET_USER_ACCESS and SYSCS_UTIL.SYSCS_GET_USER_ACCESS.
> CALL SYSCS_UTIL.SYSCS_SET_USER_ACCESS(?, null) FAILS
> ----------------------------------------------------
>
> Key: DERBY-3095
> URL: https://issues.apache.org/jira/browse/DERBY-3095
> Project: Derby
> Issue Type: Bug
> Components: JDBC, Network Client
> Affects Versions: 10.3.1.4
> Environment: Linux 2.6.17-13mdv #1 SMP Fri Mar 23 15:18:36 EDT 2007
> x86_64 AMD Athlon(tm) 64 Processor 3000+ GNU/Linux
> Reporter: EDAH-TALLY
> Attachments: d3095.sql, Reproduce3095.zip
>
>
> Sorry to bother you again.
> CALL SYSCS_UTIL.SYSCS_SET_USER_ACCESS(?, 'NOACCESS') FAILS and here's the
> stack trace :
> ******************************************************************************************
> java.sql.SQLException: Droit d'accès 'NOACCESS' inconnu.
> at
> org.apache.derby.client.am.SQLExceptionFactory40.getSQLException(Unknown
> Source)
> at org.apache.derby.client.am.SqlException.getSQLException(Unknown
> Source)
> at org.apache.derby.client.am.PreparedStatement.execute(Unknown
> Source)
> at com.somecom.createUser(someAPP.java:190)
> at com.somecom.grantKeys(someAPP.java:288)
> at com.somecom.showGrantKeys(someAPP.java:269)
> at com.somecom.MDIMenuClicked(someAPP.java:620)
> at com.somecom.access$000(someAPP.java:15)
> at com.somecom$5.actionPerformed(someAPP.java:564)
> at
> javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1995)
> at
> javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2318)
> at
> javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:387)
> at
> javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:242)
> at javax.swing.AbstractButton.doClick(AbstractButton.java:357)
> at
> javax.swing.plaf.basic.BasicMenuItemUI.doClick(BasicMenuItemUI.java:1216)
> at
> javax.swing.plaf.basic.BasicMenuItemUI$Handler.mouseReleased(BasicMenuItemUI.java:1257)
> at java.awt.Component.processMouseEvent(Component.java:6038)
> at javax.swing.JComponent.processMouseEvent(JComponent.java:3260)
> at java.awt.Component.processEvent(Component.java:5803)
> at java.awt.Container.processEvent(Container.java:2058)
> at java.awt.Component.dispatchEventImpl(Component.java:4410)
> at java.awt.Container.dispatchEventImpl(Container.java:2116)
> at java.awt.Component.dispatchEvent(Component.java:4240)
> at
> java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4322)
> at
> java.awt.LightweightDispatcher.processMouseEvent(Container.java:3986)
> at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3916)
> at java.awt.Container.dispatchEventImpl(Container.java:2102)
> at java.awt.Window.dispatchEventImpl(Window.java:2429)
> at java.awt.Component.dispatchEvent(Component.java:4240)
> at java.awt.EventQueue.dispatchEvent(EventQueue.java:599)
> at
> java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:273)
> at
> java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:183)
> at
> java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:173)
> at
> java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:168)
> at
> java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:160)
> at java.awt.EventDispatchThread.run(EventDispatchThread.java:121)
> Caused by: org.apache.derby.client.am.SqlException: Droit d'accès 'NOACCESS'
> inconnu.
> at org.apache.derby.client.am.Statement.completeExecute(Unknown
> Source)
> at
> org.apache.derby.client.net.NetStatementReply.parseEXCSQLSTTreply(Unknown
> Source)
> at
> org.apache.derby.client.net.NetStatementReply.readExecuteCall(Unknown Source)
> at org.apache.derby.client.net.StatementReply.readExecuteCall(Unknown
> Source)
> at org.apache.derby.client.net.NetStatement.readExecuteCall_(Unknown
> Source)
> at org.apache.derby.client.am.Statement.readExecuteCall(Unknown
> Source)
> at org.apache.derby.client.am.PreparedStatement.flowExecute(Unknown
> Source)
> at org.apache.derby.client.am.PreparedStatement.executeX(Unknown
> Source)
> ... 34 more
> *********************************************************************************************
> FULLACCESS : OK
> READONLYACCESS : OK
> NOACCESS : FAILURE
> By the way, the CONNECTION_PERMISSION parameter in the documentation is not
> up to date.
> Thank you for considering.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
