CREATE, READ, UPDATE, DELETE (CRUD) permissions can be set for any resource path in a VDB. A resource path can be as specific as the fully qualified name of a column or as general a top level model (schema) name. Permissions granted to a particular path apply to it and any resource paths that share the same partial name. For example, granting read to "model" will also grant read to "model.table", "model.table.column", etc. Allowing or denying a particular action is determined by searching for permissions from the most to least specific resource paths. The first permission found with a specific allow or deny will be used. Thus it is possible to set very general permissions at high-level resource path names and to override only as necessary at more specific resource paths.
Permission grants are only needed for resources that a role needs access to. Permissions are also only applied to the columns/tables/procedures in the user query - not to every resource accessed transitively through view and procedure definitions. It is important therefore to ensure that permission grants are applied consistently across models that access the same resources.
Unlike previous versions of Teiid, non-visible models are accessible by user queries. To restrict user access at a model level, at least one data role should be created to enable data role checking. In turn that role can be mapped to any authenticated user and should not grant permissions to models that should be inaccessable.
Permissions are not applicable to the SYS and pg_catalog schemas. These metadata reporting schemas are always accessible regardless of the user. The SYSADMIN schema however may need permissions as applicable.
To process a SELECT statement or a stored procedure execution, the user account requires the following access rights:
READ- on the Table(s) being accessed or the procedure being called.
READ- on every column referenced.
To process an INSERT statement, the user account requires the following access rights:
CREATE- on the Table being inserted into.
CREATE- on every column being inserted on that Table.
To process an UPDATE statement, the user account requires the following access rights:
UPDATE- on the Table being updated.
UPDATE- on every column being updated on that Table.
READ- on every column referenced in the criteria.
To process a DELETE statement, the user account requires the following access rights:
DELETE- on the Table being deleted.
READ- on every column referenced in the criteria.
To process a EXEC/CALL statement, the user account requires the following access rights:
EXECUTE (or READ)- on the Procedure being executed.
To process any function, the user account requires the following access rights:
EXECUTE (or READ)- on the Function being called.
To process any ALTER or CREATE TRIGGER statement, the user account requires the following access rights:
ALTER- on the view or procedure that is effected. INSTEAD OF Triggers (update procedures) are not yet treated as full schema objects and are instead treated as attributes of the view.