3.2.1 ACL Components

Each ACL contains a list of trustees for which access has been defined. Each entry in an ACL has the following fields:

3.2.2 ACL Operations

The following figure shows how an access control list operates. In the figure, an ACL entry has been defined for a printer object. Attributes defined for the printer include the class, the ACL, the serial number, and the owner.

Figure 3-8 An Access Control List Operation

The ACL contains the names of the protected attribute, the trustee, and the privileges. Hector appears as the trustee two times in the list: once each for [Entry Rights] and Serial Number. At the object level ([Entry Rights]), Hector is assigned the Rename, Add, Browse, and Delete privileges. He is also assigned Compare and Read on the serial number attribute. These are his privileges regarding this particular printer as an eDirectory object. This access is to the eDirectory Information Base, not the printer or its queues. The printer and queue access are controlled by the printer’s access control mechanisms, not the ACLs of eDirectory.

3.2.3 Object Rights

Object rights give a trustee rights to the eDirectory object as a whole, not just to its attributes. When dealing with security, it is important to remember that there are two distinct parts of every object: the object itself, and its properties. The syntax used to denote rights to an object is [Entry Rights]. The rights a user (or any other object) might have to another object include Browse, Create, Delete, Inheritance Control, Rename, and Supervisor. These rights are described below.

Browse

Browse rights allow the user to “see” an object. If you were getting a list of all available objects, and you didn’t have Browse rights to a particular object, such as a Container, that container wouldn’t show up in your list. Your user object wouldn’t even know the object exists.

Create

Create rights allow the user to create subordinate objects to this object, when possible. For example, if the user has Create rights to a container, the user can add other objects inside of the container.

Delete

Delete rights allow the user to delete the object. A user cannot delete an object if that user doesn’t have right to all of the properties of the object. In other words, you must have Write rights to all of the properties of an object and Delete object rights in order to actually delete an object.

Inheritance Control

NetWare® 4.x does not support this right because in NetWare 4.x, rights granted to [Entry Rights] are always inherited.

In NetWare 5.x, Inheritance Control rights allow the user to control whether [Entry Rights] granted in an ACL are inherited. If inherited, the user can exercise the rights granted in the ACL on subordinate objects. NetWare 5.x allows you to either allow inheritance or block inheritance. (NetWare 5.x utilities and their documentation call this right Inheritable.)

Rename

Rename rights allow the user to rename an object.

Supervisor

If a user has Supervisor rights to an object, it is the same as having all of the other rights (Browse, Create, Delete, and Rename) in the [Object Rights] for that object.

3.2.4 Attribute Rights

Attribute rights allow access to the data associated with an object. (NetWare utilities and their documentation call attributes, properties, and attribute rights, property rights.)

A user (or other object) can be given rights to access specific pieces of data about an object, or rights to access all information of that object. For example, if User A needs to be able to see the name, addresses, and phone numbers of User B, you can grant User A rights to each of those attributes of User B. You can also grant User A rights to all of the attributes of an object. The syntax used to denote rights to all attributes of an object is [All Attributes Rights]. If rights are given to a specific attribute, the syntax used is merely the name of that attribute. Both [All Attributes Rights] and rights to specific attributes use the same rights in a bit mask.

These attribute rights are described below:

Compare

This right gives a user the ability to test the value of an object, but not read the value. In other words, the user cannot say, “What is your password?” but can ask, “Is this password correct?”

Read

This right gives a user the ability to see the values of the attributes that are not hidden attributes. By having Read rights, the user automatically has Compare rights.

Add or Delete Self

With this right, a user can add its own object as the value of the attribute. For example, if a user has Add or Delete Self rights to the Member property of an object, such as a mailing list, the user can add itself as a member of that group.

Write

Write rights give the user the ability to add, delete, and modify the value of an attribute, as long as that attribute is not a Read Only attribute. Having Write rights implies Add or Delete Self rights.

Supervisor

If the user has Supervisor rights to an attribute, it is the same as having all of the above attribute rights to that object.

Inheritance Control

NetWare 4.x does not support this right. In NetWare 4.x, inheritance of rights granted to [All Attribute Rights] is always allowed, and inheritance of rights granted to specific attributes is always blocked.

In NetWare 5.x, Inheritance Control rights control whether the user inherits the other rights granted to a specific attribute or to [All Attributes Rights]. The bit can be set to allow or to block inheritance on both [All Attributes Rights] and specific attributes.

In NetWare 5.x, this right enables the creation of managers who have rights to manage specific attributes, such as phone numbers, addresses, and passwords, without granting Supervisor rights to the objects. If the right is granted at the container level, the right can be inheritable to an entire branch of the eDirectory tree.

An important aspect of the privilege set is the relationship between the Read and Compare privileges. Compare is considered a subset of the Read privilege. If a subject has the Read privilege, it also has the Compare privilege, whether or not Compare has been explicitly assigned to the subject. However, having the Compare privilege alone does not grant the subject the Read privilege.

3.2.5 Trustees

The administrator can create access control lists (ACL) values to assign rights or privileges to an object or attributes. The object receiving the rights assignment is called a trustee. The assignments are known as trustee assignments, or more informally as ACLs. eDirectory uses these trustee assignments in conjunction with Section 3.3, Inheritance and Section 3.3.2, Inheritance Masks to compute the effective rights a given trustee has on a given object. The given object is the object whose ACL attribute contains the trustee assignment.

The trustee assignments are created as values of the multivalued ACL attribute attached to an eDirectory object. Trustee assignments are optional.

In NetWare® 4.x, trustee assignments made to objects flow down the eDirectory tree. For example if object X is given rights to a container object A that contains object B then X gets the same rights on object B that it has on object A. However, Object B could have an inheritance mask to filter some privileges. If so X will have only the rights to access B that pass through the filter.

NetWare 5.x adds new functionality. Trustee assignments to objects can flow down the eDirectory tree just as they did in NetWare 4.x and they can be blocked with inheritance masks. However, inheritance can also be disabled with the Inheritance Control right.

In NetWare 4.x, trustee assignments made for attributes do not flow down the tree unless the assignment is for all attributes. Assignments made to specific attributes do not apply to subordinate objects or attributes of those subordinate objects.

NetWare 5.x adds new functionality. The creator of the ACL determines whether the inheritance of rights to all attributes or to specific attributes is enabled or blocked. Because NetWare 5.x allows the inheritance of rights to specific attributes, network administrators can set up managers of specific eDirectory attributes, such as phone numbers, passwords, addresses, without granting Supervisor rights to the objects.

3.2.6 Access Privileges Required for an Operation

Since a trustee can have privileges to both an object and its attributes, the combination of these privileges may determine the operations available to the subject. Some operations on attributes require that privileges be assigned at both the object and the attribute levels.

Also, some operations (such as search, list, or move) can involve more than one object. It may be useful to take a closer look at the privileges involved in specific operations. The following table summarizes the privileges required at both the object and attribute level to perform a particular operation.

It should be noted that the Supervisor privilege on an object or attribute gives the subject all privileges allowing any of the functions to be performed. However, if the Supervisor privilege is inherited, it can be restricted by an inheritance mask.

3.2.7 Managing ACLs

ACL values can be used to allow objects to change the ACL itself. Objects given certain privileges to the ACL can access it and change the rights within it. The privileges assigned in the ACL can be not only for the ACL but for the object of the ACL and all other attributes of that object.

Be careful in granting the Write, Self, and Supervisor privileges. Supervisor gives all privileges, Write allows an object to change the ACL values, and Self allows an object to add and delete itself to the value.

The Self privilege can be granted to ease the burden of managing certain attributes of objects. Giving objects the ability to add themselves to certain lists (attributes) of objects eliminates the need for a manager to add and delete those objects. An example would be a distribution list. If you made a multivalued attribute called Party Group and gave [Root] the Self privilege to that attribute, objects wishing to join your Party Group could add themselves to the group. No one could delete others from the group, but they could add or delete their own object as desired.You would want to maintain all privileges to the Party Group attribute yourself so you could read, add and delete any object at any time. This would allow you to choose to let the individuals manage their membership in the group, or manage it yourself.