Return-Path: Delivered-To: apmail-db-derby-dev-archive@www.apache.org Received: (qmail 39105 invoked from network); 11 Apr 2008 19:33:01 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 11 Apr 2008 19:33:01 -0000 Received: (qmail 64913 invoked by uid 500); 11 Apr 2008 19:33:01 -0000 Delivered-To: apmail-db-derby-dev-archive@db.apache.org Received: (qmail 64879 invoked by uid 500); 11 Apr 2008 19:33:01 -0000 Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: Delivered-To: mailing list derby-dev@db.apache.org Received: (qmail 64870 invoked by uid 99); 11 Apr 2008 19:33:01 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 11 Apr 2008 12:33:01 -0700 X-ASF-Spam-Status: No, hits=-2000.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.140] (HELO brutus.apache.org) (140.211.11.140) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 11 Apr 2008 19:32:17 +0000 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id 26415234C0C4 for ; Fri, 11 Apr 2008 12:30:06 -0700 (PDT) Message-ID: <1550153286.1207942206155.JavaMail.jira@brutus> Date: Fri, 11 Apr 2008 12:30:06 -0700 (PDT) From: "Rick Hillegas (JIRA)" To: derby-dev@db.apache.org Subject: [jira] Updated: (DERBY-3223) SQL roles: make use of privileges granted to roles in actual privilege checking In-Reply-To: <32775328.1195739983462.JavaMail.jira@brutus> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/DERBY-3223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick Hillegas updated DERBY-3223: --------------------------------- Attachment: roles.sql Thanks for the patch, Dag. I've attached a test case (roles.sql), which shows some behavior which puzzled me. This is what the patch does: 1) Creates a table and some roles. 2) Grants a select privilege to one of the roles. 3) Grants that role to another user. 4) Logs in as that user, sets that role, and successfully selects from the table. 5) Switches back to the original user and revokes the role from the second user. 6) Switches back to the second user and verifies that select privilege has been lost. So far, so good. What's puzzling me is that after the role is revoked, the second user's session still reports that its current role is the revoked role. It would have seemed more sensible to me if the current role had become null or NONE. > 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, roles.sql > > > 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.