[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Require Perms per Op
Hi All,
Here's a first pass at a description of "Required Permissions per
LDAP Operation". It includes the agreements we made at the last
tele-call about the add operation and the write permission.
Please review but I have one question in particular (don't know if this
has already been decided or not):
1. Do we need the X.500 concept of "DiscloseOnError" for every operation
? The issue here is if some required permissions are not granted then
there is a choice of whether to return "Access Denied" or "Unknown
Object", the point being if you return "Access Denied" then you are
giving out some information, namely the existence of the entry and
attribute. The closest we have to this is the "b" (browse) permission
though right now this is intended only for the Search Operation.
The question is: Should we in fact test "b" for every operation to
decide whether to tell implementors to return "Access Denied" or
"Unknown Object".
I suspect in our lightweight world the answer is "No", but then we
create one of those in the limit kind of situations "in the limit a user
could discover the directory by probing".
Rob.
999 Required Permissions for each LDAP Operation
Here, we specify the rights required by a user when performing an LDAP operation
in terms of the LDAP permissions specified in section 6.1. Recall that
"a, d, e, b" are permissions that apply to entries as a whole while permissions
"r, s, c, ma, md" apply to attributes within entries.
For the following, assume that the authorization identity of the user doing the
operation is authzID.
999.1 Search Operation
Recall that the parameters of the Search operation per RFC 2251 Section 4.5
are:
"SearchRequest ::= [APPLICATION 3] SEQUENCE {
baseObject LDAPDN,
scope ENUMERATED {
baseObject (0),
singleLevel (1),
wholeSubtree (2) },
derefAliases ENUMERATED {
neverDerefAliases (0),
derefInSearching (1),
derefFindingBaseObj (2),
derefAlways (3) },
sizeLimit INTEGER (0 .. maxInt),
timeLimit INTEGER (0 .. maxInt),
typesOnly BOOLEAN,
filter Filter,
attributes AttributeDescriptionList }"
Suppose a server is processing a search request from user authzID with
parameters as above and is processing the entry candidateDN to decide if it
may be returned or not.
Then the permissions required by authzID that need to be evaluated are as
follows:
0. permission "b" to the entry candidateDN.
If this permission is not granted then the dn candidateDN MUST not be
returned nor any attribute type nor attribute value from this entry.
If this permission is granted then the dn candidateDN MAY be returned.
1. permission "s" to each attribute in the search filter, Filter.
If there is an attribute in the filter for which permission "s" is not
granted then the dn candidateDN MUST not be returned nor any attribute
type nor attribute value from this entry.
2. If typesOnly is true:
permission "s" to each attribute in the attribute list
AttributeDescriptionList (or all attributes in the entry candidateDN if
AttributeDescriptionList is *).
If this permission is not granted to such an attribute then that
attribute type MUST not be returned.
Any attribute for which this permission is granted MAY be returned.
3. If typesOnly is false:
permissions "s" and "r" to each attribute in the attribute list
AttributeDescriptionList (or all attributes in the entry candidateDN
if AttributeDescriptionList is *).
If neither permission is granted to such an attribute then neither that
attribute type nor it's value may be returned.
If permission "s" is available to such an attribute but not permission
"r" then the attribute value MUST not be returned, while the attribute
type MAY be returned.
If permission "r" is available to such an attribute but not permission
"s" then the attribute value MUST not be returned nor that attribute
type.
999.2 Modify Operation
Recall that the parameters of the Modify operation per RFC2251 Section 4.6 are:
"ModifyRequest ::= [APPLICATION 6] SEQUENCE {
object LDAPDN,
modification SEQUENCE OF SEQUENCE {
operation ENUMERATED {
add (0),
delete (1),
replace (2) },
modification AttributeTypeAndValues } }
AttributeTypeAndValues ::= SEQUENCE {
type AttributeDescription,
vals SET OF AttributeValue }"
Then the permissions required by authzID that need to be evaluated are as
follows:
0. permission "ma" to each attribute being added to entry LDAPDN.
1. permission "md" to each attribute being deleted from entry LDAPDN.
2. permissions "md" and "ma" to each attribute being replaced in entry
LDAPDN.
If any of these permissions are not granted then the operation MUST fail.
If they are all granted then the operation MAY proceed.
999.3 Add Operation
Recall that the parameters of the Add operation per RFC2251 Section 4.7 are:
"AddRequest ::= [APPLICATION 8] SEQUENCE {
entry LDAPDN,
attributes AttributeList }
AttributeList ::= SEQUENCE OF SEQUENCE {
type AttributeDescription,
vals SET OF AttributeValue }"
Then the permissions required by authzID that need to be evaluated are as
follows:
0. permission "a" to the parent of entry LDAPDN, if the parent exists.
The access rights required for the creation of the first entry in the
Directory are beyond the scope of this document. They will be
vendor soecific.
1. permission "ma" to each attribute being added to entry LDAPDN.
If any of these permissions are not granted then the operation MUST fail.
If they are all granted then the operation MAY proceed.
999.4 Delete Operation
Recall that the parameters of the Delete operation per RFC2251 Section 4.10
are:
"DelRequest ::= [APPLICATION 10] LDAPDN"
Then the permissions required by authzID that need to be evaluated are as
follows:
0. permission "d" to the entry LDAPDN.
If any of these permissions are not granted then the operation MUST fail.
If they are all granted then the operation MAY proceed.
999.5 Modify DN Operation
Recall that the parameters of the Modify DN operation per RFC2251 Section 4.6
are:
"ModifyDNRequest ::= [APPLICATION 12] SEQUENCE {
entry LDAPDN,
newrdn RelativeLDAPDN,
deleteoldrdn BOOLEAN,
newSuperior [0] LDAPDN OPTIONAL }"
Then the permissions required by authzID that need to be evaluated are as
follows:
0. permission "e" to the entry LDAPDN.
If any of these permissions are not granted then the operation MUST fail.
If they are all granted then the operation MAY proceed.
999.5 Compare Operation
Recall that the parameters of the Compare operation per RFC2251 Section 4.10
are:
"CompareRequest ::= [APPLICATION 14] SEQUENCE {
entry LDAPDN,
ava AttributeValueAssertion }"
Then the permissions required by authzID that need to be evaluated are as
follows:
0. permission "c" to the attribute in entry LDAPDN on which the
comparison is being made.
If any of these permissions are not granted then the operation MUST fail.
If they are all granted then the operation MAY proceed.
999.6 Abandon Operation
Recall that the parameters of the Abandon operation per RFC2251 Section 4.6
are:
"AbandonRequest ::= [APPLICATION 16] MessageID"
authzID always has the right to send an Abandon Operation for an operation he
previously initiated.
999.7 Extended Operation
Recall that the parameters of the Extended operation per RFC2251 Section 4.12
are:
"ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
requestName [0] LDAPOID,
requestValue [1] OCTET STRING OPTIONAL }
The access required for an Extended Operation is beyond the scope of this
document. The required access will normally be defined by the implementor of
the extended request.
999.8 Modify RDN
???
--eof