Whole VOB protection

In order to get access to one VOB (for read or write operations), the user account needs the read-info permission on the VOB object's effective access control list.

An account without such permission is unable to open the VOB. So, to restrict access to VOB metatadata to only authorized users and groups, the administrator just needs to declare a single list of principals and grant them this permission. The rolemap protecting the VOB object, combined with the [vob] section of its policy, generates the list of authorized principals.

The storage containers in the VOB storage pools are only protected based on the element protection ACLs, even when the VOB object ACL denies access to a user's account. To keep VOB contents unreadable to unauthorized users, you should use both the effective ACL on the VOB object (for metadata) and the effective ACLs on elements (for storage containers and version data).

Exemptions from access checks

Privileged users logged into the VOB server host are exempt from the access check. The following identities skip the VOB-open permission check:
  • root logged into the VOB server host (UNIX and Linux)
  • Member of the VersionVault administrators group logged into the VOB server host (Windows)

Also, in some request-for-mastership scenarios (for example, getacl and setacl), HCL VersionVault does not check read-info permission on the VOB object. If the reqmaster ACL grants the permission to the users (VOB owners, privilege users or other users specified in reqmaster ACL), then they can open the VOB and perform the setacl or getacl operation even if they are not authorized by the VOB-open ACL.