[teiid-issues] [JBoss JIRA] Commented: (TEIID-1246) Determine access strategy for SYS/pg_catalog

[Steven Hawkins (JIRA)]

    [ https://jira.jboss.org/browse/TEIID-1246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12550160#action_12550160 ] 

Steven Hawkins commented on TEIID-1246:
---------------------------------------

The most appropriate fix seems to be to move the procedures into something like SYS.admin and to retarget the designer role editor checkbox to instead say something like "is admin".  We could also consider reintroducing something like a builtin data-admin role that could be assigned container roles and used across vdbs without the need to explicitly create the role for each.

> Determine access strategy for SYS/pg_catalog
> --------------------------------------------
>
>                 Key: TEIID-1246
>                 URL: https://jira.jboss.org/browse/TEIID-1246
>             Project: Teiid
>          Issue Type: Quality Risk
>          Components: Query Engine
>    Affects Versions: 7.1
>            Reporter: Steven Hawkins
>            Assignee: Steven Hawkins
>             Fix For: 7.1.1
>
>
> The SYS and pg_catalog schema mainly exist for metadata reporting.  It would probably be good to make the always be accessable.
> The only issue is what the access policy should be for the system procedures:
> GETCHARACTERVDBRESOURCE
> GETBINARYVDBRESOURCE
> GETVDBRESOURCEPATHS
> GETXMLSCHEMAS
> refreshMatVeiw
> refreshMatVeiwRow
> The first three are probably no longer useful as general procedures.  I'm not familiar with any customer usage.  Unless someone adds custom files to a VDB, the only thing that could be retrieved are the visible model xmis and schemas.  
> The fourth procedure is really just a helper method to get at schemas associated with a particular document model.  These resources would already be accessible via getXXXVDBResource.  Again I'm not aware of customer usage for this procedure.
> Since they are read-only and restricted to only visible entries we could just as easily always allow access to the GET procedures, or we could just as easily remove them all since they aren't particularly useful.
> That leaves us with the refresh procedures.  Theses do perform update actions and should be restricted.  One possibility is to restrict their usage based upon the permissions of the target view.  The other option is to move them into a sub schema e.g. SYS.admin.refreshMatView that would be subject to access restrictions, and can be more easily targeted by explicit roles.  If we went the role route, then the tooling could have a button to "create admin role" that would create a role named admin with all permissions including permissions against SYS.admin.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira