Historically, AccuRev has supported a security mechanism for depots and streams using Access Control Lists (ACLs). To address customer needs for more extensive security, AccuRev 5.2 introduces greatly enhanced ACL security control at the element level.
A depot ACL protects all the elements, streams, and issues in the depot. A user who has no access to the depot can still see the stream hierarchy, but none of the files in the streams. They can also not edit the streams in anyway. A stream ACL prohibits editing streams and viewing content in a stream. It can also be inheritable down the hierarchy. The table below shows what stream, depot and element ACLs restrict:
To control access to elements (files and directories), AccuRev 5.x implements a new eacl command (see
eacl on page 104 of the AccuRev
CLI User’s Guide) to set and modify
Access Control Lists (ACLs) and
Access Control Entries (ACEs). An ACL is a list of security protections that applies to an element. An ACE is an entry in an ACL that defines a
principal and a
privilege.
•
|
Full – the ability to see and view the element and to modify its ACL
|
•
|
Allow – the ability to see and view the element, but not modify its ACL
|
•
|
Readonly - prevents the user from modifying the element or its ACL during add, keep, move, defunct, and revert commands.
|
•
|
Deny – the inability to see and view the element or modify its ACL
|
An ACL contains zero or more ACEs. An element can have only one ACL assigned to it at any point in time. You specify whether to set, add, or remove an ACE (principal and privilege) to an element, and AccuRev takes care of the ACLs automatically. Note that ACLs cannot be created or modified without an element.
AccuRev security is based on AccuRev elements rather than pathnames, and this makes AccuRev security both more powerful and more complex than typical filesystem security. Don’t forget: an AccuRev element can be either a file or a directory, and can also be an element link (elink) or symbolic link (slink).
An element link (elink) is an element whose contents is a pointer to another element, which must be in the same depot. The target element can be a directory element, a file element, another element link, or a symbolic link.
Likewise, if you use element links (elinks), you must understand how AccuRev element security does and does not work apply to the link and to the destination file, otherwise a file that you think is denied to a principal may still be accessible.
In AccuRev, the same element can have multiple pathnames, depending on what streams it is in at different times. While pathnames and filenames can change, the element id (EID) never does, and this is what AccuRev security is based upon. This allows you to secure the contents of an element no matter what its current pathname is.
The third concept to keep in mind when using AccuRev element security is that ACLs are always current: they are NOT TimeSafe
®, and they are not affected by what stream they happen to appear in. This means that you cannot recreate ACLs as they appeared at a certain point the same way as you can recreate file versions or stream configurations. (You can, however, view ACL changes through the
hist command.) It also means that the appearance of a snapshot stream can change for a particular user or group, The snapshot doesn’t change—that is TimeSafe. But a user’s
access to the contents of that snapshot can change. If your access changes, the next time you perform a
pop command on your workspace, you may see files appear or disappear.
The default behavior for an element whose ACL doesn’t contain an ACE for a user is to deny access to that user. The
deny privilege overrides
allow and
full. This makes it easy to give access to everyone (all), but then deny a few. If a user has both
allow and
full, then
full privilege is granted.
The full privilege means the ability to change which ACL is associated with the element and to modify the ACL as well. A user only needs to have
allow privilege to show ACLs on an element or to view the ACL. When setting or modifying an ACL for an element, it is the current ACL associated with the element that controls the ability to set or modify the ACL. The table below describes what a user can or cannot do based on privileges:
Content is based on a static inheritance model. This means that an ACL is set for an element when assigned by the user or when it is created and inherits the ACL from its parent.
Namespace access is based on dynamic inheritance. This means that it is computed by the element’s pathname when it is accessed.
This means that if you are denied access to a particular element, you cannot see the contents or even the name of the element. However, if you are denied access to directory, but not denied access to a file in that directory, you can still perform certain operations on that file by using its EID. For example, if you know its EID, you can
cat the file. You will not be able to see its name, but you can see its contents.
The user also has the ability to set an ACL recursively down the directory tree, making it easy to assign an ACL to multiple elements. Multiple elements can be specified on the command line as well.
When you install an AccuRev release that contains element security for the first time, all elements are assigned a single default ACL created during upgrade that allows "all access". This provides new and existing customers with the exact same behavior provided by previous versions of AccuRev.
Since allow is the only privilege set during the upgrade process, you need the ability to assign ACLs or modify them afterwards. To allow this, AccuRev introduces a new
superuser role. A superuser has special security privileges to modify any ACL and assign an ACL to any element no matter what ACLs are already there. A superuser always has full access on all elements.
During the installation process you (the AccuRev Administrator) are prompted to specify an existing user or a new user to be the superuser. An administrator can also set or unset a user as a superuser through the
maintain program.:
To provide auditing (or history) capability for element security, AccuRev keeps track of all ACL changes to elements. This doesn't mean that element ACLs are TimeSafe® (and it is important to realize that element ACLs are
not TimeSafe). The most recent version of an ACL and the most recent ACL assigned to an element is always used for authorization of access. Historical information on changes to ACLs is only used for audit reporting. The
hist command is used to display the history of ACL changes on an elements.
If you are using a replica server in an EACL environment, it is critical that you set EACL permissions correctly not only for the users on the replica, but for the special replica user account (
replica-user ) that is used to communicate between the replica and the master server.
For example, assume that you want the users of a replica server to be able to access all of the files underneath folder
offshore_files, but that you do not wish them to be able to see anything under
hq_files. If you fail to assign
allow permission to
replica-user for
offshore_files, the replica may not be able to fetch any files from the master.
More importantly, if you fail to assign deny permission to
replica-user for
hq_files, it would be possible for a privileged user to log into the replica and bring the denied files down to the replica. Continuing this example, say that a privileged user from corporate headquarters visits the offshore site where the replica is being used. If the
replica-user is not correctly configured, the privileged user could log into the replica server and inadvertently bring down
hq-files elements by doing an
update. If the
replica-user is configured with
deny access to these files, the server will not send them to the replica.
•
|
less restrictive—By default, all users have allow access to all elements, unless explicitly denied.
|
•
|
more restrictive—By default, all users are denied access to all elements, unless explicitly allowed.
|
Both examples make use of the same environment: Assume that your company (“Acme Agile, Inc.”) has a new product (“Product3000”), and you will be collaborating with two partners to develop the code (“Partnership_1” and “Partnership_2”). For simplicity, these examples illustrate settings ACLs for specific users. In a real-life scenario, you would typically assign many users to various groups, and then set the element ACLs by group.
You, Acme employee user “acme_1”, create a workspace off of stream prod_3000_devel and set up the initial files and folders for the project:

Since you are a trusted user, the AccuRev administrator grants you “superuser” status so that you will be able to assign element ACLs as needed.
To make you a superuser, the AccuRev administrator logs in to the AccuRev server machine and uses the AccuRev
maintain command.
Note: The administrator must first shut down the AccuRev server before using
maintain.
Your starting point is the system default for first time AccuRev installations: everybody has allow access to all files and namespaces, and you will explicitly change privileges to certain elements for certain users to either
full or
deny.
•
|
deny means that the user cannot even see the element.
|
•
|
allow means that the user can see and work with an element, but not change its ACL
|
•
|
full means that the user not only can see and work with an element, but can also set the ACL on that element.
|
•
|
deny overrides allow and full, and if there is no explicit allow, a user is denied.
|
In this case, you want to grant the user from Partnership_1 (“part_1”)
allow privileges on the
partner_1 files, but
deny that user any privileges on the
partner_2 files or the
acme_proprietary files. Likewise, the user from Partnership_2 (“
part_2”) should have
allow privileges to the
partner_2 files, but
deny privilege to the
partner_1 and
acme_proprietary files.
Note: It is conceivable that partners might want
full access to their own files so that they could set specific ACLs for their own users. However, the
full privilege is very powerful and should not be granted unless absolutely necessary. A partner with
full access could deny you access to files on your own system, or inadvertently
deny access to everybody, both of which would require superuser intervention.
Both partners should retain allow access to the Acme
common_files folder and its contents.
Finally, you (acme_1) want to have
full privileges on all elements in the project. To set up these ACLs:
Note: Since we want to leave the default
all:allow ACL in place for all the files in the project, and explicitly adjust the ACLs of specific files and specific users, it is critical that we use the
-a (add) option here, and not
-n (new). If we had specified
-n, user
acme_1 would have been granted
full access, while
removing access for everybody else. Removing access is the same as specifying
deny.
Again, note the use of -a, which retains the default
allow access to these elements for other users (such as other Acme employees). Using
-n here to set
deny access to the partners would have been the same as setting
all:deny, since it would have removed the default
all:allow setting.
Once you (acme_1) promote all these elements up the stream, the effect of the ACLs becomes obvious.
Note: The
promote has nothing to do with setting EACLs; it is just that the files were being set up for the first time in
acme_1’s workspace and do not even exist in the stream hierarchy until they are promoted.
When you (acme_1, who has
full accesss to all elements) view the contents of the prod_3000_itr stream, all folders and elements are visible. In the following example, the elements in partner_2 are displayed

However, if user part_1 logs in and views the same stream, he or she sees a very different display. Only the
partner_1 files and the common Acme files are visible. From user
part_1’s perspective, the
partner_2 and Acme proprietary files and folders do not even exist.

User part_2 would see a similar display, except the
partner_2 files and folder would be visible, while those of
partner_1 could not be seen.
Note: Although the ACL setting is not visible from the GUI, an ACL list from the CLI will reveal that while user
acme_1 has
full access to the
partner_1 elements and user
part_2 has no access to the
partner_1 elements, user
part_1 has
allow access to the Acme common files through the default
all ACL:
Similar to the previous scenario, we will start by giving user acme_1 full access to all project files, but this time we will use the
-n option instead of
-a:
Note: Unlike the previous scenario which used
-a, all users except
acme_1 are now denied access to all elements in the project by default.
4.
|
Explicitly grant the Partnership_1 user (part_1) allow access to the Partnership_1 files and to the Acme common files. Note that unlike the previous example, it is necessary now to explicitly grant allow access to the common files, since the all:allow default ACL was implicitly removed in Step 2.
|
Because the default setting in this scenario is to deny access to users who have not been explicitly granted access, the above steps only address users acme_1, part_1, and part_2. You would need to continue these procedures to grant access to other Acme users as needed. In a real-life scenario, you would typically assign users to groups and assign ACLs to those groups rather than to individual users.