Each AccuRev user must have an AccuRev username (also called a "principal-name"). AccuRev maintains its own user registry in the repository; it is separate from the registry maintained by your machine's operating system (or the network).
Optionally, you can create AccuRev user groups, and add users to the groups as "members". Starting in Version 4.5, groups can be nested within one another; that is, a group can be a member of another group. AccuRev groups are independent of operating system groups.
AccuRev groups are used by the Access Control List (ACL) facility to grant or deny access to a particular resource for an entire set of users. They are used by the
Locks facility to specify a set of users to which a stream lock does or does not apply.
Each AccuRev group has a user-defined name. Usernames and groupnames share a "namespace" in the AccuRev repository. This means that a user and a group cannot have the same name.
With a few exceptions, a user cannot execute AccuRev commands unless he is authenticated as an AccuRev user. For authentication purposes, each registered AccuRev user has a username/password pair recorded in the registry. A user's password can be empty.
AccuRev automatically distinguishes two categories of users — those who have non-empty passwords and those whose passwords are empty. The keywords
authuser and
anyuser, respectively, are used by the ACL facility to designate these categories.
Most AccuRev users are authenticated by explicitly logging in to the AccuRev Server. Using the GUI or the CLI, the user logs in by entering his username and password (possibly empty). This launches a user session, which is typically of limited duration (a few hours). When the session expires, the user must login again to continue using most AccuRev commands.
A successful login command creates an encrypted session file that records the user's AccuRev username and password, along with the IP address of the client machine. If an AccuRev client command can be executed only by an authorized user, the command automatically sends the information in the session file to the AccuRev Server process. Thus, the user doesn't need to repeatedly 'remind' the AccuRev Server who (and where) he is.
AccuRev also supports script-based authentication of AccuRev users. For example, customers with an LDAP authentication scheme in place at their organization could configure a script to authenticate AccuRev users via LDAP. See the "AccuRev Security Overview" chapter in the
AccuRev Administrator's Guide for further details.
Each stream can have one of more locks on it. A lock prevents a certain set of users from using the stream to create new versions of elements. That is, it prevents execution of the
Promote command -- either promoting from the designated stream, or promoting to the designated stream, or promoting in either direction.
A lock can be absolute, applying to all users. Alternatively, you can specify that a lock applies to a particular AccuRev user, or to a particular AccuRev group. Conversely, you can specify that a lock applies to everyone
except a particular AccuRev user, or to everyone
except a particular AccuRev group.
In addition to (or instead of) locks, each stream can have one of more permissions on it. Whereas a lock controls the ability to create new versions (through the
Promote command), a permission is more general: in addition to controlling
Promote, it controls the ability to read data from the stream, using such commands as
Annotate,
Diff, and
Open. A permission also controls workspace-specific commands, such as
Update and
Populate.
You can also create an ACL permission that applies to an entire depot. This provides a way of controlling access to all of a depot's file system data, in all streams. It also provides a way to control access to issues in a depot.
As of Release 5.2, AccuRev also provides element-level ACLs (or “EACLs”). EACLs can only be set by an AccuRev administrator, and can only be set and modified using CLI commands. GUI users can be denied access to elements or directories if an administrator has configured EACLs. Depending on the situation, you will either see an “Access Denied” error message, a
(no such elem) status, or the element will be completely invisible to you, as if it doesn’t exist:
•
|
For commands that specify an eid, such as cat, the command will succeed if you are not denied access to that element. If you are denied access to the namespace of the element, the eid is displayed instead of the name.
|
•
|
Commands that modify workspaces, such as update and pop, will succeed even if you are denied access to some of the elements, but those elements will not be brought down to the workspace. The exception to this is if you specify the element name, such as with pop or co. In this case the command will fail as if the element doesn’t exist.
|
•
|
For commands such as stat, dirstruct, and files, where you specify an option or nothing instead of an element name, if you are denied access to either the namespace or content, nothing will be displayed for that element. For example, stat –d displays all the elements in the default group of the stream. If you are denied access to an element in the default group, it will not be displayed.
|
•
|
Display a (no such element) status. If your access to an element or namespace changes during a session, and you are now denied access to something that was already displayed, that element or folder will appear with the (no such element) status.
|
For information about element ACls, see Chapter 10 Element Security in the
AccuRev Administrator’s Guide, and the command summary for
eacl on page 104 of the
AccuRev CLI User’s Guide
ACL permissions apply to a stream regardless of any basis time on the stream. Similarly, ACL permissions can be placed on a
snapshot, even though such permissions are necessarily created after the snapshot is created.
By default, any registered AccuRev user can execute any AccuRev command. Many organizations wish to restrict users' access to certain commands, such as the ability to maintain users, groups, and passwords, the ability to lock streams and create ACL permissions, and so on. Triggers provide a flexible mechanism for implementing command-based security.
A pre-operation trigger can affect the execution of the command or cancel it altogether. Typically, a security-related trigger checks the identity of the user invoking the command, then decides whether or not to allow the command to proceed.
Some triggers are configured on a per-depot basis, using the mktrig command. These triggers monitor individual commands (
add,
keep, and
promote). Three are pre-operation triggers that fire on the client machine; one is a post-operation trigger that fires on the server machine.
Other triggers are configured, on a per-depot or whole-repository basis, by placing a script in a well-known location on the server machine. These triggers monitor groups of commands, rather than individual commands.
•
|
a pre-promote-trig trigger script, which runs on the client machine
|
•
|
a server_preop_trig trigger script, which runs on the server machine
|