Relatively low impact issue currently. Didn't seem like Dell Engineers would be reaching out to NetVault counterparts. I'm just putting this here so my job is done if the right people see it.
NetVault Devs may already be aware, but in case they are not...
One of the Data Domains that we manage is a shared backup target where tenants bring their own backup software. Tenants are provided pre-created local users (with role access of none) on the Data Domain and given a pre-created storage unit (LSU) with quota assigned. We noticed that a particular tenant using NetVault was able to create additional storage units on the Data Domain even though their access level is none. This allowed them to bypass quotas and create storage units that did not follow naming conventions, not ideal in a shared backup target.
Here's the RCA response from Dell Engineering:
We've confirmed that NetVault uses the ddp_storage_unit_create() Boost API to create the storage unit, whereas the recommended method is to use the DD REST API.
1. The RBAC policy is enforced only for DD CLI and REST API but not for Boost API calls. This is by design.
2. This is the current behavior - SU create is allowed for all Boost users (regardless of ‘role’) and SU modify/delete is disallowed for all Boost users that do not have the ‘admin’ role.
The Boost APIs for storage-unit management operations will be deprecated in a future release and non-enforcement of the RBAC policy is a known issue which is by design (for legacy apps). NetVault should be using the DD REST APIs for all storage-unit management operations so that the RBAC policy for the tenant-unit user is honored.
References:
Dell SR 21835805
Quest SR 4973146
Thanks!
Peter
