AccuRev Security Overview

Users and Groups

Usernames and Groupnames

User Authentication

The "Traditional" User-Authentication Scheme

The "AccuRev Login" User-Authentication Scheme

Locks on Streams

Access Control List (ACL) Permissions

Restricting Access to Commands using Triggers

Which Security Feature Should I Use?

This topic presents an overview of AccuRev's security-related features. We discuss and compare the following topics, and provide pointers to more detailed documentation.

Users and Groups

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.

Groups are used by the 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.

Usernames and Groupnames

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.

User Authentication

With a few exceptions, a user cannot execute AccuRev commands unless he is authenticated as a registered 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.

The "Traditional" User-Authentication Scheme

Prior to Version 4.5, AccuRev supported a single scheme for authenticating users. This is now termed the "traditional" scheme. In this scheme, a user's AccuRev username is, by default, the same as his operating-system login name. The user can establish a different username by setting environment variable ACCUREV_PRINCIPAL.

Whenever the user invokes a command that requires user authentication:

  1. AccuRev determines the username, by getting the value of ACCUREV_PRINCIPAL from the environment, or by asking the operating system for the user's login name.

  2. If there's a non-empty password for this username in the AccuRev user registry, AccuRev compares this password with the contents of file authn, located in subdirectory .accurev of the user's operating-system home directory. The user is authenticated as an authuser if the strings match (case-sensitive). If they don’t match, the user gets notauth status.

If there's an empty password for this username in the AccuRev user registry, AccuRev still checks the authn file. The user is authenticated as an anyuser if the file is empty.

The "AccuRev Login" User-Authentication Scheme

Starting in Version 4.5, AccuRev also supports a scheme wherein a user is authenticated by explicitly logging in to the AccuRev Server. Using the GUI or the CLI, the user invokes the Login command and enters his 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 A file in the .accurev subdirectory of your home directory, which establishes your user identity for a particular AccuRev Server. 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.

If a user is already logged in, and he successfully logs in again — as the same user or a different user — the existing session file is overwritten.

Locks on Streams

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.

Locks can also prevent reconfiguration of the contents of a stream with the include/exclude facility.

For more on locks, see the description of the Locks command.

Access Control List (ACL) Permissions

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.

Unlike locks, which always apply to individual streams, ACL permissions can be configured to apply to entire stream subhierarchies.

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 a depot's AccuWork issue database.

ACL Permissions and Time Considerations

ACL permissions apply to a stream regardless of any basis time A date-timestamp setting for a stream, affecting which versions the stream inherits from its parent stream: for each element, the version inherited is the one that was in the parent stream at the basis time. See snapshot. on the stream. Similarly, ACL permissions can be placed on a snapshot An immutable (frozen, static) stream that captures the configuration of another stream at a particular time. A snapshot cannot be renamed or modified in any way., even though such permissions are necessarily created after the snapshot is created.

For more on ACL permissions, see the description of the ACL subtab of the Security tab.

Restricting Access to Commands using Triggers

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.

Many AccuRev commands can be configured to "fire a trigger". This causes a user-defined script to execute ...

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.

For more on triggers, see description of the Triggers tab and the chapter "AccuRev Triggers" in the AccuRev Administrator's Guide.

Which Security Feature Should I Use?

AccuRev's security features overlap to a considerable extent. For example, when a user invokes the promote command, any of these mechanisms can prevent the command from proceeding:

How do you decide which feature to use in a given situation? There are no absolute rules, but here are some guidelines:

To script or not to script?

The trigger mechanism depends on execution of user-supplied scripts, written in Perl, Python, or some other scripting language. There's a trade-off: scripting required development time and significant expertise, but is infinitely flexible.

In many situations, you may be able to use the AccuRev software distribution's sample Perl scripts, which are designed for fill-in-the-blanks customization.

It makes sense to implement as much security as possible with locks and ACL permissions (and perhaps the sample trigger scripts), before delving into original trigger scripting.

Locks vs. ACL permissions

Roughly speaking, a lock controls the placing of data into a stream, whereas an ACL permission controls the reading of data from a stream. (There are plenty of exceptions to this general rule.)

Both locks and permissions can be targeted at specific users or groups. The ACL is more flexible: you can create any number of permissions for the same stream, but only limited number of locks.

Running trigger scripts: client machine vs. server machine

Running trigger scripts on the client machine conserves networking and server resources. But keep in mind that all client machines must have copies of the scripts (or must have network access to a central script repository).

Running trigger scripts on the server machine provides administrative simplicity and centralized logging.