[
https://issues.apache.org/jira/browse/DERBY-4502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rick Hillegas updated DERBY-4502:
---------------------------------
Attachment: derby-4502-01-aa-dummyUUID.diff
Attaching derby-4502-01-aa-dummyUUID.diff. This fixes the problem. I am running
regression tests now.
The quick fix is to give the dummy permissions descriptor a dummy UUID, viz.,
the UUID of the system table. A more elaborate fix would be to allocate a new
set of UUIDs, one for each system table, and use those UUIDs instead. The more
elaborate fix would be useful if we ever wanted to regard UUIDs as
self-describing object IDs, capable of reconstructing the objects they
identify. However, that is not how we use UUIDs today. Today, looking up an
object involves knowing both its UUID and the object's type (e.g., table,
index, constraint, function, procedure, trigger, etc..). With this fix, we
maintain the current contract: UUIDs are unique within a given type namespace.
Migrating to the more elaborate scheme should be possible if we decide later on
that we want UUIDs to be self-describing.
In writing the regression test for this problem, I tripped across another bug:
After a reboot, the system SchemaDescriptors have a null authorization id. I
fixed this problem by poking the correct authorization id into the system
SchemaDescriptors during database reboot.
Touches the following files:
M java/engine/org/apache/derby/impl/sql/catalog/PermissionsCacheable.java
This is the fix to the bug described by this JIRA. A dummy UUID is added to the
implicit permission descriptors which are cooked up to represent SELECT
privilege granted to PUBLIC on the system tables.
M java/engine/org/apache/derby/impl/sql/catalog/DataDictionaryImpl.java
M java/engine/org/apache/derby/iapi/sql/dictionary/SchemaDescriptor.java
This is the fix to the reboot problem in the DataDictionary.
M
java/testing/org/apache/derbyTesting/functionTests/tests/lang/GrantRevokeDDLTest.java
Regression test case for this bug.
> Can't define view against system table when SQL authorization is
> enabled--attempting to do so kills your connection
> -------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-4502
> URL: https://issues.apache.org/jira/browse/DERBY-4502
> Project: Derby
> Issue Type: Bug
> Components: SQL
> Reporter: Rick Hillegas
> Attachments: derby-4502-01-aa-dummyUUID.diff
>
>
> Derby fails on an NPE if you try to create the following view when
> authorization is turned on:
> create view v2( a ) as select tablename from sys.systables;
> The NPE occurs when the dependency manager trips across a dummy permission
> constructed on-the-fly. The dummy permission is created by
> PermissionsCacheable and is supposed to represent the implicit grant to
> PUBLIC of SELECT privilege on the system table. PermissionsCacheable doesn't
> bother to give the dummy permission a corresponding dummy UUID. The
> dependency manager falls down when trying to deference the null UUID of the
> dummy permission.
> The following script shows this problem:
> connect
> 'jdbc:derby:memory:dummy;create=true;user=test_dbo;password=test_dbopassword'
> as test_dbo_conn;
> connect 'jdbc:derby:memory:dummy;user=ruth;password=ruthpassword' as
> ruth_conn;
> create table t( b int );
> create view v1( a ) as select b from t;
> create view v2( a ) as select tablename from sys.systables;
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
