db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kathey Marsden (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-2109) System privileges
Date Fri, 29 Feb 2008 17:14:51 GMT

    [ https://issues.apache.org/jira/browse/DERBY-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12573849#action_12573849
] 

Kathey Marsden commented on DERBY-2109:
---------------------------------------

The J2ME run had other problems, perhaps related to:
r632125 | djd | 2008-02-28 13:43:25 -0800 (Thu, 28 Feb 2008) | 5 lines

DERBY-3445 Adds ant targets to run the junit-all tests with EMMA code coverage.
Fixes some permission issues in tests when running coverage with EMMA.
DERBY-3153 Allows the junit-all tests to be run with ant 1.7 

.......Parsing policy file: jar:file:/C:/jartest/classes/derbyTesting.jar!/org/a
pache/derbyTesting/functionTests/util/derby_tests.policy, found unexpected: perm
ission
EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE.EEE.EEEE.EE.EEEEEEEE.E.E.
E.E.E.E.E.E.EEE.E.E.E.EEEEEE.E.E.E.E.E.E.E.E.EEEEEEEEEEEEEEEEEEEEEEEEEEE.EEEEEE.
EEE.E.E.E.E.E.
E.E.E.E.E.E.E.E.E.E.E.E.E.E.E.E.E.E.E.E.E.E.E.E.E.E.E.E.E.E.E.E.E.E.E.E.E.E.E.E.
E.
E.E.E.E.E.E.E.E.E.E.E.E.E.EEEE.E.EEEEEEEEEEEEEEEEEEEjava.sql.SQLException: Java
exception: 'Access denied (java.util.PropertyPermission user.dir read): java.sec
urity.AccessControlException'.
        at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknow
n Source)
        at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Unknown Source)
        at org.apache.derby.impl.jdbc.Util.javaException(Unknown Source)
        at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException
(Unknown Source)
        at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Un
known Source)
        at org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown So
urce)
        at org.apache.derby.impl.jdbc.EmbedConnection.<init>(Unknown Source)
        at org.apache.derby.jdbc.Driver169.getNewEmbedConnection(Unknown Source)
        at org.apache.derby.jdbc.InternalDriver.connect(Unknown Source)
        at org.apache.derby.jdbc.EmbeddedSimpleDataSource.getConnection(Unknown
Source)
        at org.apache.derby.jdbc.EmbeddedSimpleDataSource.getConnection(Unknown
Source)
        at org.apache.derbyTesting.junit.DataSourceConnector.openConnection(Data
SourceConnector.java:54)
        at org.apache.derbyTesting.junit.TestConfiguration.openDefaultConnection
(TestConfiguration.java:1312)
        at org.apache.derbyTesting.junit.BaseJDBCTestSetup.getConnection(BaseJDB
CTestSetup.java:72)
        at org.apache.derbyTesting.functionTests.tests.jdbcapi.SURDataModelSetup
.setUp(SURDataModelSetup.java:119)
        at junit.extensions.TestSetup$1.protect(TestSetup.java:18)
        at junit.framework.TestResult.runProtected(TestResult.java:124)
        at junit.extensions.TestSetup.run(TestSetup.java:23)
....

I will take a closer look and file a Jira entry.

As for the split code it was added June 6. revision 544870 as part of DERBY-2109.  
Is it possible that the new patch causes that code to be exercised for the first time?




> System privileges
> -----------------
>
>                 Key: DERBY-2109
>                 URL: https://issues.apache.org/jira/browse/DERBY-2109
>             Project: Derby
>          Issue Type: New Feature
>          Components: Security
>    Affects Versions: 10.3.1.4
>            Reporter: Rick Hillegas
>            Assignee: Martin Zaun
>         Attachments: DERBY-2109-02.diff, DERBY-2109-02.stat, derby-2109-03-javadoc-see-tags.diff,
DERBY-2109-04.diff, DERBY-2109-04.stat, DERBY-2109-05and06.diff, DERBY-2109-05and06.stat,
DERBY-2109-07.diff, DERBY-2109-07.stat, DERBY-2109-08.diff, DERBY-2109-08.stat, DERBY-2109-08_addendum.diff,
DERBY-2109-08_addendum.stat, DERBY-2109-09.diff, DERBY-2109-09.stat, DERBY-2109-10.diff, DERBY-2109-10.stat,
DERBY-2109-11.diff, DERBY-2109-11.stat, DERBY-2109-12.diff, DERBY-2109-12.stat, SystemPrivilegesBehaviour.html,
systemPrivs.html, systemPrivs.html, systemPrivs.html, systemPrivs.html
>
>
> Add mechanisms for controlling system-level privileges in Derby. See the related email
discussion at http://article.gmane.org/gmane.comp.apache.db.derby.devel/33151.
> The 10.2 GRANT/REVOKE work was a big step forward in making Derby more  secure in a client/server
configuration. I'd like to plug more client/server security holes in 10.3. In particular,
I'd like to focus on  authorization issues which the ANSI spec doesn't address.
> Here are the important issues which came out of the email discussion.
> Missing privileges that are above the level of a single database:
> - Create Database
> - Shutdown all databases
> - Shutdown System
> Missing privileges specific to a particular database:
> - Shutdown that Database
> - Encrypt that database
> - Upgrade database
> - Create (in that Database) Java Plugins (currently  Functions/Procedures, but someday
Aggregates and VTIs)
> Note that 10.2 gave us GRANT/REVOKE control over the following  database-specific issues,
via granting execute privilege to system  procedures:
> Jar Handling
> Backup Routines
> Admin Routines
> Import/Export
> Property Handling
> Check Table
> In addition, since 10.0, the privilege of connecting to a database has been controlled
by two properties (derby.database.fullAccessUsers and derby.database.defaultConnectionMode)
as described in the security section of the Developer's Guide (see http://db.apache.org/derby/docs/10.2/devguide/cdevcsecure865818.html).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message