1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
|
ACL Layer Design for the Wallet
Introduction
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.
Syntax
An ACL entry in the wallet consists of two pieces of data, a <scheme>
and an <instance>. <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.
Semantics
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 and
the <identifier> portion of the ACL entry. 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
krb5
The <identifier> is a fully-qualified Kerberos principal. Access is
granted if the principal of the client matches <identifier>.
netdb
<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).
netdb-root
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.
ldap-entitlement
(Not yet implemented.) <identifier> is an entitlement. If the
entitlement attribute of the LDAP entry corresponding to the given
principal contains the entitlement specified in <identifier>, access
is granted.
pts
(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.
|
