ACL Layer Design for the Wallet


This is a description of the ACL layer of the wallet implementation. This is a specification of the expected behavior of the ACL implementation and includes the syntax and semantics of ACL strings used in the database. The ACL entries used by the wallet are intended to be an extensible format to which additional ACL backends may be added as needed. When new ACL backends are added, they should be described here.


An ACL entry in the wallet consists of two pieces of data, a <scheme> and an <identifier>. <scheme> is one or more characters in the set [a-z0-9-] that identifies the ACL backend to use when interpreting this ACL. <identifier> is zero or more characters including all printable ASCII characters except whitespace. Only the implementation of <scheme> knows about the meaning of <identifier>. <identifier> may include zero or more users.


All users are authenticated to the wallet by Kerberos and are therefore represented by a Kerberos principal, which follows the normal Kerberos rules for string representation.

Whenever there is a question about whether a user is permitted an action by a particular ACL, the following verification algorithm is used: Iterate through each ACL entry in the ACL in question. If the ACL entry is malformatted or the scheme is not recognized, skip it. Otherwise, dispatch the question to the check function of the ACL implementation, passing it the principal identifying the client, the <identifier> portion of the ACL entry, and the type and name of the object the user is attempting to access. This function returns either authorized or unauthorized. If authorized, end the search; if unauthorized, continue to the next ACL entry.

There is no support in this scheme for negative ACLs.

There is one slight complication, namely that some ACL methods need to maintain persistant state for performance reasons (consider, for example, an ACL layer implemented with LDAP queries). Therefore, each ACL handler should be represented by an object, and when the ACL code discovers it doesn't already have an object on hand for a given ACL scheme, it should construct one before querying it. If construction fails, it should fail that scheme and any ACL that uses that scheme, but still allow access if an ACL not using that scheme grants access to the user.

ACL Schemes


The <identifier> is arguments to an external command. Access is granted if the external command returns success. The standard remctl environment variables are exposed to the external command.


The <identifier> is a fully-qualified Kerberos principal. Access is granted if the principal of the client matches <identifier>.


<identifier> is an an attribute followed by an equal sign and a value. If the LDAP entry corresponding to the given principal contains the attribute and value specified by <identifier>, access is granted.


This is almost identical to netdb except that the user must be in the form of a root instance (<user>/root) and the "/root" portion is stripped before checking the NetDB roles.


<identifier> is the name of another ACL, and access is granted if it is granted by that ACL. This can be used to organize multiple ACLs into a group and apply their union to an object.


<identifier> is the name of a system. Access is granted if the user is listed as an administrator, user, or admin team member of the host in NetDB (Stanford's system management database).


This is almost identical to netdb except that the user must be in the form of a root instance (<user>/root) and the "/root" portion is stripped before checking the NetDB roles.


(Not yet implemented.) <identifier> is the name of an AFS PTS group. Access is granted if the principal of the user is a member of that AFS PTS group.


Copyright 2016 Russ Allbery <>
Copyright 2006-2008, 2013

The Board of Trustees of the Leland Stanford Junior University

Copying and distribution of this file, with or without modification, are permitted in any medium without royalty provided the copyright notice and this notice are preserved. This file is offered as-is, without any warranty.

SPDX-License-Identifier: FSFAP

Converted to XHTML by faq2html version 1.36