Preventing privileged VOB access by remote users

HCL VersionVault allows you to prevent privileged access by users who are not logged on to the local host.

Commands that create VOBs or change their protection allow you to restrict privileged VOB access to users who are logged on to the VOB server host. When such restrictions are in place, no user is considered privileged unless he is logged on to the VOB server host as a privileged user, and any request from a privileged user logged on to a remote host is treated as a request from an ordinary user: it fails if a privileged identity is required. This restriction can be applied as needed, on a VOB-by-VOB basis. Existing VOBs can be re-protected, using the protectvob command, to disallow remote access by privileged users. The mkvob and mkreplica commands allow you to specify at VOB-creation time whether privileged remote access is allowed. In addition, a site property can be set to control the default behavior of mkvob and mkreplica with respect to allowing privileged remote access. For more information, see the reference pages for protectvob, mkvob, and mkreplica.

Protecting a VOB against privileged access by remote users does not affect remote operations unless they require privileged access. Remote or local operations on objects owned by the user or by a group of which the user is a member are not affected. To ensure that these restrictions can be applied only by a user who has the privileges needed to override or remove them, they can be applied only by someone who is logged on to the VOB server host as a privileged user.

Privileged operations that affect multiple VOBs

Some operations, such as modification of cross-VOB hyperlinks or global types that have existing local copies, modify objects in multiple VOBs. When these VOBs are on different hosts and do not allow privileged access by remote users, the following rules apply:
  • If the operation modifies a global type that has local copies, the privileged user must be logged on to the VOB server host for the VOB in which the global type resides.
  • If the operation modifies a cross-VOB hyperlink, it is sufficient for a privileged user to be logged on to either of the VOB server hosts involved.