You can translate the question and the replies:

Row restriction preventing user from utilizing view in a derived view in their own Denodo database.

We are running V7.0.20201003. Thanks for any insight that can be provided on the following security scenario we are struggling with. A view (v1) is created in database d1. Column access is granted to col1, col2 on v1 to a user’s AD group. Row access granted col1 =’X’ to the user’s AD group. The user can successfully execute a SELECT statement on v1. For example, SELECT col1, col2 FROM d1.v1 returns only rows where col1 is ‘X’. However, if they attempted to create a derived view based on this same SELECT statement in their own Denodo database (d2), they get an error indicating that they don’t have permissions to do so due to row restrictions on v1. If we remove the row restrictions, they can successfully create their derived view. Is there a way to enable the user to create their derived view without having to drop the row restriction? Our reason for wanting to do this is to facilitate cross-Denodo database data access. Different teams have their own Denodo databases. Our thought is that we don’t want the team to create a d2 data source and base view based on v1 because any changes to d1.v1 might break their d2 base view. Thanks!
05-02-2021 11:35:30 -0500

3 Answers

Hi, I was able to reproduce the same error when I tried to create a derived view, over the view that is having “**Column/Row restrictions**”. This behavior occurs because, in the Denodo Platform 7.0, the **user/role with column/row restrictions over a view is not allowed to create a view derived from this view**, as mentioned in the section [Enforcing Column Privileges, Row Restrictions, and Custom Policies ]( of Virtual DataPort Administration Guide. Hence at the moment, in the Denodo Platform 7.0, the user with column/row restrictions over a view can only execute a select statement on it. If you need more assistance, you can raise a support case in the [Denodo Support Site]( if you are a valid support user. For more information, you can refer to [User and Access rights in Virtual DataPort]( of Virtual DataPort Administration Guide. Hope this helps!
Denodo Team
08-02-2021 07:10:29 -0500
Thanks for the information! It is interesting to note that the derived view creation in the d2 database only fails when a row restriction exists; it works fine with column restrictions. So to achieve our goal of enabling a team (t1) to expose their data to another team (t2) and have t2 be able to use it as a component of their Denodo-based logic, would you recommend that t2 create a base view for t1's view? Or is there another technique we should consider? Our potential concern with the t2 base view approach is that any changes to t1's d1.v1 view might break t2's base view.
08-02-2021 11:37:47 -0500
Hi, To create a view including the restrictions and without creating a view in d2 over the view view1 of d1, I would log in to Virtual DataPort Administration Tool with the admin user account. First, I would execute the below command from the VQL Shell: * SET 'com.denodo.vdb.catalog.user.User.enableCheckViewRestrictionAlways' = 'true'; If I want to enable this behavior over a specific database or all of them, I would execute the below command: * SET 'com.denodo.vdb.catalog.user.User.checkViewRestrictionAlways' = 'true'; By executing the above commands the user is allowed to create views over a view with restrictions if it has the right privileges (CREATE or CREATE VIEW). For more information, you can refer to [Enforcing Restrictions On All Queries]( of the Virtual DataPort Administration guide. Hope this helps!
Denodo Team
16-02-2021 07:59:18 -0500
You must sign in to add an answer. If you do not have an account, you can register here