8.5 THE PERMISSIONS NEEDED FOR EACH OPERATION

Table 8.4 lists the permissions that are needed for each Directory operation. The following sections describe each operation in more detail.

An important principle that guided the designers of the access control scheme is that if a user does not have access rights to some or all of the information required by an operation, then the operation result or error returned to the user will be the same as if that information did not exist in the Directory. In other words, the operation result or error will be the same as the one the user would have received, if the only information present in the Directory was information to which the user did have access rights. Fig. 8.4 summarises the responses that are given to a user for each combination of information present and permission to access it. It can be seen that the user is only allowed to access the information, when they have the appropriate permission. It is impossible for a user to deduce that information is present in the Directory, but that they do not have permission to access it, since the Directory response to this is the same as if the information was not present. The precise response received by the user will depend upon the operation and the permission that is denied. For example, when reading attributes from an entry, those for which permission is denied will simply be omitted from the result. If permission to read the entry is denied, then the user will be given the error response Name Error (No such object).

However, if the information owner so desires it, it is possible to disclose to a user that the information is present, but that they do not have access rights to it. This is achieved by giving the user a minimum permission (DiscloseOnError), the effect of which is either to qualify a result as having some information missing, or to turn a Not Present error response into a Security Error 'insufficient access rights'.

8.5.1 Read Operation

In order for the Read operation to be evaluated, first of all the user needs to have Read permission for the entry (grant Read for protected item entry). If this permission is not available (no permission or deny Read present) then an error will be returned to the user. This error will normally be Name Error with problem no such object, which is the same error that is returned to a user when an entry genuinely does not exist. However, if the user has been granted permission to know that the entry does exist in the case where an error has occurred (grant DiscloseOnError permission for the protected item entry), then a Security Error with problem insufficient access rights will normally be returned. The user is thus told that they do not have sufficient access rights for the operation. (An administrator who wishes her system to be slightly less revealing, should have the option, which is allowed in the Standard, of configuring it to return a Security Error with the problem no information. The availability of this option will depend upon a manufacturer's particular implementation.)
 
Fig. 8.5 Responses given to a user with and without Read permission to the attributes of an entry (Read operation with specific attributes selected).

If the user only wishes to read the types of attribute present in the entry, then they must have Read permission (grant Read) for each attribute type that is returned in the result. Attribute types for which the user has no Read permission, are excluded from the result.

If this would mean that no attribute types are returned, then an error is returned to the user instead of an empty set of entry information.

If the user wishes to read attribute types and values from the entry, then a similar set of rules to the ones above are defined. The user must have Read permission to all the attribute types returned, but also the user must have Read permission to all the attribute values returned in the result. If Read permission to an attribute type is missing, then the attribute will not appear in the result, irrespective of whether or not the user has permission to read one or more of the values (w/w 8.2). If a user has Read permission to an attribute type, but not to any of its values, then an empty set of values is returned. If the user does not have permission to read any of the attribute types or values in the entry, then the same error (i.e. Attribute or Security Error) is returned as described above for reading attribute types only.

When a Read result is incomplete, because the user did not have Read permission to one or more of the attribute types or values that were requested, the user is normally unaware that some information has been withheld. The user is led to believe that it did not exist. However, if the user has DiscloseOnError permission to any of the omitted pieces of information, the user is told that they only received part of the entry information. (This is notified via the incompleteEntry boolean in the response being set to True.)

8.5.2 Compare Operation

The access permissions needed for the Compare operation are similar to those needed for the Read operation. First of all, Read permission for the entry is required. Without this permission an error (Name Error or Security Error as described in 8.5.1) is returned. Secondly Compare permission (grant Compare) for the attribute type is needed. Without this, an Attribute Error with problem No Such Attribute Or Value is normally returned, unless the user has DiscloseOnError permission to the attribute type, in which case a Security Error would be returned.

Finally, the user needs Compare permission (grant Compare) for each attribute value that is to be compared against the presented one. Attribute values without this permission are ignored. True will be returned to the Compare operation, only if an identical attribute value to that presented by the user, actually exists in the entry, and the user has Compare permission to it.
Note. 'Identical' actually means that the value presented by the user gives a True response when comparing it to an attribute value stored in the entry, using the equality matching rule defined for the attribute (§ 5.7).

8.5.3 List Operation

The List operation is unusual, in that no permission is required at the entry whose children are to be listed. Instead, Browse and ReturnDN permissions (grant Browse and grant ReturnDN for item entry) are needed for each subordinate entry whose RDN is to be included in the result. Entries not yielding these permissions are ignored, but if no subordinate entries grant the user both permissions, then an empty set of results or an error is returned to the user. The latter decision depends upon whether or not the user has permission to know that the parent entry exists when an error occurs (grant DiscloseOnError for item entry). With this permission, an empty set of subordinates is returned. Without this permission, Name Error (no such object) is returned.

There is an added complication with the List operation, which arises if some of the subordinates are in other DSAs. The DSA will need to chain the operation to the subordinate DSAs, unless a copy of all the necessary information is held locally.
Note.The totality of information needed by the superior DSA, for complete local processing of the List operation, is: the access control information, the RDN, and the object class of the subordinate entry. The latter is needed in order to determine if the subordinate is an alias or not.
 Likewise, the subordinate DSA, in order to correctly process a request generated from a continuation reference, needs the access control information of the superior entry when the user does not have browse and returnDN permission to the subordinates. Without this information, a Service Error (invalid reference) must be returned to the user. With this information, and if the user has discloseOnError rights to the superior entry, an empty set of subordinates may be returned.

The Hierarchical Operational Binding is designed to provide this information, and to keep it up to date, and so with this in place, chaining will not be required. The DSA will be able to process the List operation locally. Without a Hierarchical Operational Binding providing all the information, the DSA will need to either chain the operation to the subordinate DSAs and merge the returned results, or return a continuation reference to the requestor. There are no additional security requirements for chaining, as the subordinate DSAs can each check the user's access rights to the subordinate entries before returning the RDNs.

But what if the user forbade chaining via the chaining prohibited service control, or if the DSA's policy is not to chain? In the former case, a Service Error with problem chaining required may be returned to the user. In the latter case a Continuation Reference will be added to the result. However, if the result consists solely of Continuation References, and does not hold the names of any subordinates, then the user must have DiscloseOnError permission to the parent entry in order to receive them. Otherwise the user receives a Name Error (no such object). This is to stop a user with no permissions at all, from determining that the parent entry exists, which of course they can infer from the returned continuation reference.

8.5.4 The Search Operation

The Search operation is also peculiar, in that, like the List operation, it does not require any permissions on the base object in order for the evaluation of the operation to start. Instead, each entry in the user requested scope of the Search operation, i.e. baseObject, oneLevel or wholeSubtree, needs to have Browse permission (grant Browse) in order for it to be included in the scope by the Directory. (For scopes of base object and whole subtree, then obviously the base object would need to have Browse permission for it to be included in the scope.) If no entries are included in the scope, due to a complete lack of Browse permissions for the user, then either an empty set of entries is returned - if the user has DiscloseOnError permission for the base object - or alternatively a Name Error (no such object) is returned.

For each entry that has been included in the scope of the Search, the next step is to evaluate the filter. This requires permission to use the attributes held in the entry for matching against items in the filter (w/w 8.3). Permission is first required to use the attribute type for filtering (grant FilterMatch for item attributeType). If permission is not given, then the filter item evaluates to undefined. This is exactly the same result as if the attribute were not present in the entry. If permission is given, then filter items using attribute types can be evaluated straight away. Filter items using attribute values also require FilterMatch permission on each attribute value that is to be used in the matching. Values without the grant FilterMatch permission are ignored. Any attribute values with FilterMatch permission, are evaluated against the filter item, and will yield True or False. If no value permissions are granted, a filter item will evaluate to False. After completing the evaluation of the filter, an entry will either be selected for or discarded from inclusion in the Search result.

The next step is to decide which information from each selected entry may be included in the Search result. This process is very similar to that used for selecting information from an entry for inclusion in a Read result. Read permission (grant Read) is needed for each of the attribute types chosen by the user. Without this permission, an attribute is omitted from the result. The only difference between a Read and a Search result, is that the selection of no attributes by the Directory causes an error response to be sent to the Read, whereas with Search an empty entry is returned. If attribute types and values were requested by the user, then processing of this is identical to that of the Read operation. Read permission is required for each attribute type and value returned in the result. An empty set of values will be returned if permission was given to read an attribute type but not to any of its values.

The final step is to determine if the names of the selected entries can be returned to the user. If the user has ReturnDN permission to a selected entry, then its distinguished name will be returned in the result. If the user does not have ReturnDN permission, then clearly the distinguished name cannot be returned. Instead, the DSA may substitute a known alias name for the entry, and return this to the user. The Standard says that it is a local (i.e. implementation) matter how the DSA knows the name of an alias of the entry. If no alias name is known by the DSA, then the selected entry unfortunately has to be discarded from the set of results, since the DSA is unable to return a name for it.

Finally, the user may be given notification that an entry in the result does not contain all the information that they requested (via incomplete entry boolean set to True). This will be given if any of the omitted attribute types or values have permission to disclose their presence if an error has occurred (grant DiscloseOnError). (In this case the error is that the user did not have Read permission to the attribute or value.) Without DiscloseOnError permission, the user will be led to believe that the omitted information was not present in the entry.

The complication arising from entries within the scope of the Search, residing in other DSAs, has also been addressed. Chaining does not pose an additional security risk to the superior DSA, but returning Continuation References to the user does. Therefore, if the result consists solely of Continuation References, the user must have DiscloseOnError permission at the base entry, in order to receive them. Without this, the user will receive a Name Error (no such object) response, exactly as with the List operation.

8.5.5 AddEntry Operation

Permission to add an entry can normally only be given by PrescriptiveACI, since the access control information that is held in an entry, does not yet exist - unless the entry already exists! Thus the system administrator has to purposely give permission to users to add entries before they can do so. PrescriptiveACI Add permission might typically only be given to a selected few administrators, rather than to every employee. This helps to protect the Directory from being populated in an uncontrolled manner. If all employees were to be allowed to add their own entries, then Add permission to user class 'this entry' would be needed in the PrescriptiveACI.

First of all, the user requires Add permission for the new entry being added (grant Add for item entry). Without this permission, the operation will fail. Using the principle outlined in § 8.5 and Fig. 8.4, that without permission, a user is always told that information is not present in the Directory, the user will receive a Name Error (No Such Object). The matched component of the error will either point to the next superior above the entry to be added, for which the user has grant DiscloseOnError permission, or if there are none, point to the root of the DIT. Note that this error will be returned, even if the entry already exists i.e. if it was previously added by someone else. In this way the unauthorised user cannot glean information from the Directory, by finding out via error diagnostics, what is present. The only exception to the return of the Name Error (No Such Object), is if the user has the minimum permission (grant DiscloseOnError) to the entry to be added. The error (s)he will receive will then depend upon whether or not the

Fig. 8.6 Responses given to a user with and without Add permission for the entry (AddEntry operation).

entry actually exists. If it does, the user will receive Update Error (Entry Already Exists), but if it does not, then they will receive a Security Error (either Insufficient Access Rights or No Information). The responses generated by the Directory are summarised in Fig. 8.6.

Assuming the user has Add permission to the entry, the user then requires Add permission for each attribute type and value that is to be added to the entry (grant Add to all items). If just one item is lacking Add permission, then the operation will fail with the above Security Error.

If the user has Add permission, but the entry is already present in the Directory, then they will be told that the entry already exists.

The only complication with the AddEntry operation, comes from adding an entry across DSA boundaries. Local security policy may forbid this, in which case the superior DSA may return any appropriate error - such as Update Error (Affects Multiple DSAs) - providing that the user has DiscloseOnError permission to the superior entry. If this permission is not available, Name Error (No Such Object) should be returned, as described above.

8.5.6 RemoveEntry Operation

The RemoveEntry operation is the simplest operation in terms of access control. The only permission needed by the user is to be able to remove the entry (grant Remove on item entry). No further permissions are required. In the absence of this permission, the normal Name Error (No Such Object) should be returned, unless of course the user has the minimum permission grant DiscloseOnError to the entry to be removed, in which case a Security Error will be returned.

8.5.7 ModifyEntry Operation

The user requires permission to modify the entry (grant Modify for item entry). Without this permission, and according to the first guiding principle, the user will be told that the entry does not exist (Name Error (No Such Object)). However, if the user is allowed to know of its existence during the occurrence of an error (DiscloseOnError permission is granted), then a Security Error will be returned (either Insufficient Access Rights or No Information).

The user also requires Add permission for each attribute type and value to be added, and Remove permission for each attribute type and value to be removed (w/w 8.2). If any one permission is not granted, then the whole operation fails with an error diagnostic. Deriving the error message that is returned is complex, and is based on the logic of the first guiding principle, though this has to be modified when applying it to adding information to the Directory (but see w/w 8.4). Figs 8.7, 8.8 and 8.9 show the error messages that are returned when: adding attributes, adding attribute values, and removing attributes and values respectively.

When trying to add an attribute type or value, a user is only told that it already exists (Attribute Error (Attribute Or Value Already Exists)), if they have permission to add the information, or failing that, DiscloseOnError permission to the information. Without these permissions, the user who is adding an attribute is returned a Security Error with a problem code of either Insufficient Access Rights or No Information, irrespective of whether or not the attribute exists (Fig. 8.7).

Fig. 8.7 Responses given to a user with and without Add permission for the attribute (ModifyEntry operation).

When adding attribute values, a user without the Add or DiscloseOnError permissions is told that the information does not exist (via the Attribute Error (No Such Attribute Or Value)) irrespective of whether or not the information already exists. (Incidentally, this error is also returned to users who have permission to add an attribute value, when the attribute does not yet exist in the entry. In other words the operation should have been to add an attribute, and not an attribute value.) The only exception to the 'does not exist' deception, is if the user has DiscloseOnError permission to the already existing attribute type, in which case they receive a Security Error (Fig. 8.8).

Fig. 8.8 Responses given to a user with and without Add permission for the attribute value (ModifyEntry operation).

Note that it is not usually possible to give someone permission to modify a single attribute value, since the ModifyEntry operation is based on adding and removing values. Giving someone permission to remove a single value is possible (as in ACI Item VE3 in Fig. 8.12) but not to add a single value, since the value to be added would need to be quoted in the ACI, and it does not exist! (The only time that users can be given permission to modify a single attribute value is with item selfValue on values of attributes whose syntax are distinguished names.)

When trying to remove information, the usual error message in the absence of Remove permission, is that the information is not present in the Directory (Attribute Error (No Such Attribute Or Value)) - this error message is also given to authorised users who specify non existent attributes and/or values. However, if DiscloseOnError permission has been granted, and the attribute or value is present, then a Security Error is returned to the user (Fig. 8.9).

Fig. 8.9 Responses given to a user with and without Remove permission for the attribute type or value (ModifyEntry operation).

8.5.8 ModifyDN Operation

Because this operation has evolved from the 1988 ModifyRDN operation, there are two styles of use. Each style has its own associated access control permissions.

If the operation is being used to modify the RDN of an entry, then Rename permission is needed for the entry (grant Rename for item entry). No further permissions are required. Without Rename permission, the user is told that the entry does not exist (Name Error (No Such Object)), unless DiscloseOnError permission has been granted, in which case a Security Error is returned to the user.

If the operation is being used to move an entry (or a subtree) to a new superior in the DIT, then Export and Import permissions are required. The user requires Export permission for the entry being moved (grant Export for item entry). Even if a whole subtree is being moved, as might be the case when an organisation restructures itself, Export permission is only required for the entry at the apex of the subtree. The subordinates tag along behind it to their new home. The user also requires Import permission for the space (entry) in the DIT where the entry is to be placed. This permission can only be given via a PrescriptiveACI, analogous to the AddEntry situation. Without either permission, the user receives the same error as in the ModifyRDN style of use.

If the operation simultaneously moves an entry and changes its RDN (Fig. 5.8), then all of the above permissions are needed.

8.5.9 Dereferencing Aliases

No permissions are required to dereference an alias, as long as the user is not told the name of the aliased object. Thus, if an alias points to another entry in the same DSA, or to an entry in another DSA and the request is chained between the DSAs, then the name of the aliased object is kept secret within the Directory system. When the target object is eventually reached, the grant ReturnDN permission will control whether or not the user is given the distinguished name of the target entry, or the name of one of its aliases (§ 8.6). The important thing to note is that the Directory is not concerned about keeping secret the names of aliases, but rather the aliased objects that they point to.

There are problems though, if referrals instead of chaining takes place. With referrals, the aliased object name may be returned to the user. In order to try and control this, the following permissions are required before the dereferencing DSA will return a Continuation Reference in a referral, or in a List or Search partial result. The user requires Read permission for the alias entry, for the Aliased Object Name attribute and for the attribute's single value. If any of these permissions are missing, then instead of a referral, an Alias Dereferencing Problem is returned (§ 5.18.2), and in the case of a List or Search operation, the continuation reference is omitted from the partial result.

This mechanism is not completely watertight, since a subsequent DSA in a chain might return a referral, and the aliased object might then be deducible from this. No solution is currently available for this problem.