Restrictions placed on positive access rights have the goal of restricting the granted rights. The meaning of conditions on negative (denied) access rights is unclear. We intend to investigate this issue, however, for the time being, we require that:
1) A single EACL entry must not specify both positive and negative rights.
2) If an EACL entry specifies negative rights, it must not have any conditions.
If both negative and positive authorizations are allowedf in individual or group entries, inconsistencies must be resolved according to resolution rules. The design approach we adopted allows the ordered interpretation [11] of EACLs. Evaluation of ordered EACL starts from the first to the last in the list of EACL entries. The resolution of inconsistent authorization is based on ordering. The authorizations that already have been examined take precedence over new authorizations.
Other interpretations are possible, but we found that for many such policies, resolution of inconsistencies was either NP-Complete or undecidable.
In general, when an EACL grants a requested opertation and no additional credentials are required, the GAA API will look for credentials that can cause denial. A principal may chose to withhold credentials that it believes may result in a denial. There may be interactions when independent credentials are used, i.e., one set of credentials causes denial, but the other causes accept. The administrator must deal with these issues by carefully setting policies in an EACL. It may be appropriate to specify a more restricted set of rights and require grant credentials to be presented.
Conflicts may arise when more then one entry applies. For example, one matching entry specifies individual subject (user, host or application), and another matching entry spesifies a certain group name. In this case, one would expect the entry for the individual subject to be placed before the entry for the group, on the assumption that the policy expressed by the individual subject entry is an exception to the policy expressed by the group entry. When several EACL entries with different conditions apply, the access is based on the conditions in the first matching entry found. An ordered evaluation approach is easier to implement as it allows only partial evaluation of EACL and resolves the authorization conflicts. The problem with this approach is that it requires total ordering among authorizations. It requires careful writing of EACL by the security administrator and is error-prone. Disordering of the EACL entries may result in discrepancies between the intended policy and the one that results from evaluation of the EACL. It might be useful to have a separate module [4], [9], that would help verify and debug the EACL to assure that it expresses the desired policy.