Bug 780826 (SOA-3276) - Roles which do not allow access to a user-defined function, will allow access via table
Summary: Roles which do not allow access to a user-defined function, will allow access...
Keywords:
Status: CLOSED NOTABUG
Alias: SOA-3276
Product: JBoss Enterprise SOA Platform 5
Classification: JBoss
Component: EDS
Version: 5.2.0.ER2
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ---
: ---
Assignee: Default User
QA Contact:
URL: http://jira.jboss.org/jira/browse/SOA...
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-08-17 21:33 UTC by Paul Nittel
Modified: 2011-08-18 14:17 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-08-18 14:17:24 UTC
Type: Bug


Attachments (Terms of Use)
RolesWithFunction_MPS.zip (497.02 KB, application/zip)
2011-08-17 21:36 UTC, Paul Nittel
no flags Details
teiid-security-roles.properties (380 bytes, application/octet-stream)
2011-08-17 21:36 UTC, Paul Nittel
no flags Details
teiid-jboss-beans.xml (16.07 KB, text/xml)
2011-08-17 21:36 UTC, Paul Nittel
no flags Details
RolesVDB.vdb (18.55 KB, application/octet-stream)
2011-08-17 21:36 UTC, Paul Nittel
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker SOA-3276 0 None None None Never

Description Paul Nittel 2011-08-17 21:33:33 UTC
project_key: SOA

Given a role that grants access to a table whose transformation uses a UDF, but does NOT grant access to the function itself, the user possessing that role is able to query the table.

For example, "tester1" has "role1" and is able to execute "SELECT PART_NAME, SecretCode FROM PartsVirtual.usesFunction". Role1 does not grant access to the UDF. Here's the role as seen in the VDB:

    <data-role allow-create-temporary-tables="false" any-authenticated="false" name="Data Role 1">
        <description>Allow READ of source A and virtual model, but NOT sourceB</description>
        <permission>
            <resource-name>PartsVirtual</resource-name>
            <allow-create>false</allow-create>
            <allow-read>true</allow-read>
            <allow-update>false</allow-update>
            <allow-delete>false</allow-delete>
        </permission>
        <permission>
            <resource-name>Soundex</resource-name>
            <allow-create>false</allow-create>
            <allow-read>false</allow-read>
            <allow-update>false</allow-update>
            <allow-delete>false</allow-delete>
        </permission>
        <permission>
            <resource-name>PartsSourceB</resource-name>
            <allow-create>false</allow-create>
            <allow-read>false</allow-read>
            <allow-update>false</allow-update>
            <allow-delete>false</allow-delete>
        </permission>
        <permission>
            <resource-name>PartsSourceA</resource-name>
            <allow-create>false</allow-create>
            <allow-read>true</allow-read>
            <allow-update>false</allow-update>
            <allow-delete>false</allow-delete>
        </permission>
        <mapped-role-name>role1</mapped-role-name>
    </data-role>

All of the PartsVirtual resource is readable, including the usesFunction table. When this query is executed by tester1, the table is successfully queried. It should not be.

I'll attach a bunch of artifacts.

Comment 1 Paul Nittel 2011-08-17 21:36:02 UTC
Attachment: Added: RolesWithFunction_MPS.zip
Attachment: Added: teiid-security-roles.properties
Attachment: Added: teiid-jboss-beans.xml
Attachment: Added: RolesVDB.vdb


Comment 2 Van Halbert 2011-08-17 21:54:24 UTC
I disagree.  I think this is the way we want it.   It follows the same pattern as roles for tables.   Example, if you have 3 layers of models (physical and 2 virtual layers), and only expose the top layer (i.e., set permissions), then only the top layer is executable by the user.   But you don't have to enable permissions on the lower models that are used in transformations at the top level in order for the user to execute a query.   The lower models have their permissions turned off so that users can't directly execute them.   This would be the same behavior for functions.

Comment 3 Paul Nittel 2011-08-18 14:16:58 UTC
After mulling it over, I agree with Van, that this is how it should work. So, I'm self-rejecting this Jira.

Comment 4 Paul Nittel 2011-08-18 14:17:24 UTC
I entered it. I rejected it. I'm closing it.


Note You need to log in before you can comment on or make changes to this bug.