[jira] Updated: (DERBY-3223) SQL roles: make use of privileges granted to roles in actual privilege checking

["Dag H. Wanvik (JIRA)" <ji...@apache.org>]

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

Dag H. Wanvik updated DERBY-3223:
---------------------------------

    Attachment: derby-3223-1a.stat
                derby-3223-1a.diff

Uploading an experimental patch, 3223-1a, which adds privileges
granted to roles to the set of privileges available to a session user,
in addition to privileges granted to that user and to PUBLIC. 
Code to handle revocation logic when role grants are revoked,
privileges grants are revoked from roles, modifying the current role,
and dropping roles is included.

- Role descriptors are still not cached in memory. This is/may be a
  performance issue, of course. The present implementation naively
  fetches role descriptors from disk as needed.

- If an execute privilege is conferred via a role, and that role is
  revoked from a user (directly or indirectly via inheritance), the
  dependent object (constraint, trigger, view) will be dropped, that
  is, the RESTRICT semantics is not used.  This is in contrast to when
  such a privilege is revoked from a role (or user), in this case, the
  RESTRICT semantics apply.  Since privilege revocation for the
  different privileges are not compatible with regards to
  RESTRICT/CASCADE, I need to find a workable solution for this choice
  when revoking roles (which can confer all kinds of privileges).

- Resetting the current role role for the current session leads to
  invalidation of dependent prepared statements (they need to be
  checked again), which is too expensive, cf discussion with Dan on
  this.  I will look into if I can invalidate just the activations
  instead.

- Similar to the present solution fopr GRANT/REVOKE, when privileges
  are revoked, for dependent persistent objects (constraint, trigger,
  view), there is no attempt to find an alternative privilege which
  can apply: For example, if the discretionary privilege to user U is
  revoked, there is no attempt to find an applicable privilege granted
  to PUBLIC instead; the object is dropped, or RESTRICT kicks in as
  the case may be. This holds when privileges are revoked from roles
  as well.

  This situation is bad for roles, since, in the general case, when
  dependencies are inherited through a role grant graph, the present
  implementation records dependencies on the current role set (it does
  not record not the entire path of grant descriptors leading through
  the role grant graph from the current role up to the role which
  received the privilege grant). This has the consequence that when a
  revoke is performed on a role high up in a role inheritance graph,
  all downstream roles in the transitive closure of the grant relation
  of that role are invalidated, which may lead to excessive
  invalidations (and hence objects drops) in some cases.
  
  For dependent prepared statements, this is only a performance issue,
  since DDL operations are rare enough that some extra recompilations
  should be ok.

- Roles are applied only after discretionary and public privileges are
  exhausted, with one exception: A full table select permission to a
  role will be preferred over column selects to user or public. This
  order determines the behavior at revoke time for persistent objects,
  cf previous bullet.

The usual disclaimers for experimental code; bugs, lacking comments,
lacking tests, code reduncancy which need refactoring, etc, etc apply :)

Please kick the tires and see if the behavior is what you would
expect.


> SQL roles: make use of privileges granted to roles in actual privilege checking
> -------------------------------------------------------------------------------
>
>                 Key: DERBY-3223
>                 URL: https://issues.apache.org/jira/browse/DERBY-3223
>             Project: Derby
>          Issue Type: New Feature
>          Components: Security, SQL
>            Reporter: Dag H. Wanvik
>            Assignee: Dag H. Wanvik
>             Fix For: 10.5.0.0
>
>         Attachments: derby-3223-1a.diff, derby-3223-1a.stat
>
>
> Pushing out to 10.5

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