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

[Ramesh Reddy (JIRA)]

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

Ramesh Reddy commented on TEIID-1246:
-------------------------------------

How would user define "sys" and "pg_catalog" be always accessible? should user needs to still define in the vdb.xml or these names will hard coded some where to get automatic access?

I like the "SYSADMIN" role and model. This completely removes any configuration that is VDB based for these in-built models from VDB.

> 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