To control access to elements (files and directories), AccuRev 5.x implements a new eacl command (see eacl 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
|
|
•
|
Read only - 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
|
Element-based security
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).
A key concept to master is how ACLs apply to the element versus the element’s contents. See Inheritance to understand how access to contents and namespace differs,
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.
When you install an AccuRev release that contains element security for the first time, all elements are assigned the allow privilege. This provides new and existing customers with the exact same behavior provided by previous versions of AccuRev, but it does not permit existing privileges to be modified: modifying an element privilege (an EACL) requires the full privilege.
Only AccuRev users identified as a superuser are granted the full privilege needed to modify element privileges. The superuser always has full access to all elements and is needed to begin the process of setting up element security, and to fix problems that users may cause, such as denying everyone access to an element.
The AccuRev administrator can set or unset a user as a superuser using the maintain program, as follows.
maintain su -a <principal_name>
maintain su -r <principal_name>
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.
|
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:
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.
The administrator restarts the AccuRev server, and you log in to the AccuRev CLI as acme_1 and start assigning EACLS as shown below.
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.
|
|
•
|
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.
Finally, you (acme_1) want to have full privileges on all elements in the project. To set up these ACLs:
|
1.
|
Log in to the AccuRev CLI with the acme_1 superuser account.
|
|
2.
|
Change to the workspace directory for the prod_3000_devel project and grant yourself (acme_1) full access to all project files.
|
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.
-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.
|
4.
|
Deny Partnership_1 any access to Partnership_2 files, while granting allow access to them to the Partnership_2 user (and retaining the default all:allow access to all other users).
|
|
5.
|
Deny Partnership_2 any access to Partnership_1 files, while granting allow access to them to the Partnership_1 user (and retaining the default all:allow access to all other users).
|
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:
This scenario is similar to the less restrictive scenario above, except that the default privilege for all users to all files will be deny. We will then adjust ACLS to increase privileges as needed.
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:
|
1.
|
Log in to the AccuRev CLI with the acme_1 superuser account.
|
|
2.
|
Change to the workspace directory for the prod_3000_devel project and use the -n option to grant yourself (acme_1) full access to all project files, replacing the default all:allow ACL.
|
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.
|
3.
|
Explicitly grant the user from each partnership allow access to the top of the project tree (but do not recurse through the tree structure, since we want to be selective about what they can and cannot access):
|
|
4.
|
Now, provide the Partnership_1 user (part_1) and Partnership_2 user (part_2) allow access to the partners directory:
|
|
5.
|
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.
|
|
6.
|
Likewise, explicitly grant the Partnership_2 user (part_2) allow access to the Partnership_2 files and to the Acme common files.
|