[
https://issues.apache.org/jira/browse/DERBY-4030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12667447#action_12667447
]
Dag H. Wanvik commented on DERBY-4030:
--------------------------------------
When you run with requireAuthentication and SQLAuthorization enabled, only
the database owner is authorized to encrypt the database, cf.
http://db.apache.org/derby/docs/10.4/ref/rrefattrib15290.html and
http://db.apache.org/derby/docs/10.4/devguide/tdevcsecureunencrypteddb.html
In the sample program, a connect is attempt with a user (OTHERUSER)
that is not the database owner where the property dataEncryption is
set to true. This is why the first connect fails, as it should.
Unfortunately, to be able to check the user credentials, Derby has to
boot the database (without encrypting it)
before it can fail the connect since the database owner is not known a priori.
It is a known weakness that it will remain booted in such
cases if the authorization check fails.
(If it succeeds, the database will be shutdown and rebooted
with encryption happening.)
I think we discussed at the time this was implemented whether
this is an error or not; the latter view prevailed, see DERBY-2407.
The second time around in your repro, the database is already booted, but this
time the
encryption property is silently ignored unfortunately (logged as DERBY-2409) -
it is only
heeded at boot time, so the connect succeeds, since this is a legal user.
If you are ok with this explanation, please close this issue as invalid.
> Derby tried to reencrypt DB when other than owner connects
> ----------------------------------------------------------
>
> Key: DERBY-4030
> URL: https://issues.apache.org/jira/browse/DERBY-4030
> Project: Derby
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 10.4.2.0
> Environment: Linux 2.6.27.7 #3 SMP Sun Nov 30 17:18:23 CET 2008
> x86_64 AMD Turion(tm) 64 X2 Mobile Technology TL-60 GNU/Linux
> java version "1.6.0_10"
> Java(TM) SE Runtime Environment (build 1.6.0_10-b33)
> Java HotSpot(TM) 64-Bit Server VM (build 11.0-b15, mixed mode)
> Reporter: EDAH-TALLY
> Fix For: 10.4.2.1
>
> Attachments: DerbyIssue3.java
>
>
> DB : with requireAuthentication and SQLAuthorization enabled
> DB owner connects painlessly
> Another user tries to connect : first connection fails with Connection
> Exception 08004 :
> User '<authorizationID>' cannot (re)encrypt database '<databaseName>'. Only
> the database owner can perform this operation.
> StackTrace :
> java.sql.SQLNonTransientConnectionException: L'utilisateur 'OTHERUSER' ne
> peut pas (réen)coder la base de données '/tmp/DerbyIssue3'. Seul le
> propriétaire de la base de données est habilité à effectuer cette opération.
> at
> org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(Unknown
> Source)
> at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Unknown
> Source)
> at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Unknown
> Source)
> at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Unknown
> Source)
> at org.apache.derby.impl.jdbc.EmbedConnection.newSQLException(Unknown
> Source)
> at org.apache.derby.impl.jdbc.EmbedConnection.checkIsDBOwner(Unknown
> Source)
> at org.apache.derby.impl.jdbc.EmbedConnection.<init>(Unknown Source)
> at org.apache.derby.impl.jdbc.EmbedConnection30.<init>(Unknown Source)
> at org.apache.derby.impl.jdbc.EmbedConnection40.<init>(Unknown Source)
> at org.apache.derby.jdbc.Driver40.getNewEmbedConnection(Unknown
> Source)
> at org.apache.derby.jdbc.InternalDriver.connect(Unknown Source)
> at org.apache.derby.jdbc.AutoloadedDriver.connect(Unknown Source)
> at java.sql.DriverManager.getConnection(DriverManager.java:582)
> at java.sql.DriverManager.getConnection(DriverManager.java:154)
> at DerbyIssue3.connect(DerbyIssue3.java:83)
> at DerbyIssue3.main(DerbyIssue3.java:26)
> Caused by: java.sql.SQLException: L'utilisateur 'OTHERUSER' ne peut pas
> (réen)coder la base de données '/tmp/DerbyIssue3'. Seul le propriétaire de la
> base de données est habilité à effectuer cette opération.
> at
> org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source)
> at
> org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(Unknown
> Source)
> ... 16 more
> Second connection in same running JVM succeeds.
> The other user seems to work normally afterwards.
> Sample program is attached to reproduce the exception.
> Don't know if it has already been reported, didn't find a similar one.
> Thank you for investigating.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
