[teiid-issues] [JBoss JIRA] Issue Comment Edited: (TEIID-952) Column level security capabilities

[ https://issues.jboss.org/browse/TEIID-952?page=com.atlassian.jira.plugin.... ] Steven Hawkins edited comment on TEIID-952 at 1/25/11 2:04 PM: --------------------------------------------------------------- Marking as rejected unless an implementation proposal and compelling use case are provided. In any case, this has a limited scope - only user level SELECT * queries, which are typically avoided by application logic. There has also never been clarity on how this should work. Past proposals if someone issues a SELECT * query against a table containing a read protected value: 1. return empty data. However there is no clear indication to the user that his data has been altered. The vdb designer could also manually implement this approach by adding a view with a definition along the lines of "SELECT CASE WHEN HASROLE('foo') THEN protectedCol END, otherCol, ..." - null will be returned if the user does not have the given role. 2. to remove un-privileged columns in SELECT *, but leave the metadata as is. This is the most straight-forward, but I can't find any precedent for this behavior and it is logically inconsistent with the reported metadata. 3. change the metadata (as reported by the system tables and in resultset metadata, etc.) to remove un-privileged columns and remove hidden columns from top level SELECT * queries. This is only clearly correct if the user lacks all permissions against the column (select/insert/update). with mixed permissions it's unclear if the column should be hidden. This also introduces complications with the system table logic that assumes we can create cached forms of the odbc metadata - since the data is not specific to a given user. The workaround is also quite simple, just remove the offending column(s) by entering the full SELECT clause. was (Author: shawkins): Marking as rejected unless an implementation proposal and compelling use case are provided. In any case, this has a limited scope - only user level SELECT * queries, which are typically avoided by application logic. There has also never been clarity on how this should work. Past proposals if someone issues a SELECT * query against a table containing a read protected value: 1. return empty data. However there is no clear indication to the user that his data has been altered. 2. to remove un-privileged columns in SELECT *, but leave the metadata as is. This is the most straight-forward, but I can't find any precedent for this behavior and it is logically inconsistent with the reported metadata. 3. change the metadata (as reported by the system tables and in resultset metadata, etc.) to remove un-privileged columns and remove hidden columns from top level SELECT * queries. This is only clearly correct if the user lacks all permissions against the column (select/insert/update). with mixed permissions it's unclear if the column should be hidden. This also introduces complications with the system table logic that assumes we can create cached forms of the odbc metadata - since the data is not specific to a given user. The workaround is also quite simple, just remove the offending column(s) by entering the full SELECT clause. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira