db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dag H. Wanvik (JIRA)" <j...@apache.org>
Subject [jira] Updated: (DERBY-3743) Revoking EXECUTE privilege on a function if used in a CHECK constraint: implementation problem
Date Wed, 02 Jul 2008 06:46:45 GMT

     [ https://issues.apache.org/jira/browse/DERBY-3743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Dag H. Wanvik updated DERBY-3743:

    Attachment: derby-3743.stat

Enclosing two patches. The first, derby-3743-show-constraint-invalidate-actions,
adds a test case to GrantRevokeDDLTest.

In this test case, an EXECUTE privilege on a function (f_abs) is attempted
revoked when there exists a CHECK constraint that is dependent on it.

The patch also instruments ConstraintDescriptor to show what action is used
when prepareToInvalidate is called. Derby correctly restricts the revoke, but I
think the implementation is possibly wrong. I came upon this when trying to
make revoke work for roles.

As can be seen from running GrantRevokeDDLTest with this patch, the action that
INTERNAL_RECOMPILE_REQUEST. I think it should properly be

However, when the constraint is created, there is no dependency registered on
the applicable permission descriptors when the constraint is a CHECK
constraint, cf the code section for "case DataDictionary.CHECK_CONSTRAINT:" in

This is in contrast to the case for FOREIGN KEY constraints (which may
depend upon REFERENCES privileges). For the latter case, the method
storeConstraintDependenciesOnPrivileges is called, which does record
dependencies for the constraint on the applicable permissions.

For the CHECK constraint case, the only dependeny registered is on the function
itself (the alias descriptor), cf. CreateConstraintConstantAction, ca line 398.

So, when the EXECUTE privilege is revoked, in
RoutinePrivilegeInfo#executeGrantRevoke, there are two invalidation
actions called:

            DependencyManager.REVOKE_PRIVILEGE_RESTRICT, lcc);
            DependencyManager.INTERNAL_RECOMPILE_REQUEST, lcc);

The former does not lead to the RESTRICT enforcement, since there is no such
dependency registered, as shown. The latter does lead to RESTRICT enforcement,
however, but I think this is just a side effect and not how

I enclose a patch, derby-3743, which changes the implementation so
that REVOKE_PRIVILEGE_RESTRICT is the action that leads to the
RESTRICT enforcement by adding a dependency on the EXECUTE permission
descriptor for CHECK constraints.

Running regressions, please review.

> Revoking EXECUTE privilege on a function if used in a CHECK constraint: implementation
> -----------------------------------------------------------------------------------------------
>                 Key: DERBY-3743
>                 URL: https://issues.apache.org/jira/browse/DERBY-3743
>             Project: Derby
>          Issue Type: Improvement
>          Components: Security, SQL
>    Affects Versions:
>            Reporter: Dag H. Wanvik
>         Attachments: derby-3743-show-constraint-invalidate-actions.diff, derby-3743-show-constraint-invalidate-actions.stat,
derby-3743.diff, derby-3743.stat
> The docs say that REVOKE EXECUTE ... RESTRICT should 
> fail if there is a dependent constraint:
> "The RESTRICT clause specifies that the EXECUTE privilege cannot be
>  revoked if the specified routine is used in a view, trigger, or
>  constraint, and the privilege is being revoked from the owner of the
>  view, trigger, or constraint."
>  Revoking the privilege will be correctly restricted, but possibly for the wrong reason.

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

View raw message