Open
Bug 236492
Opened 21 years ago
Updated 19 years ago
SDK should handle and print out Get Effective Rights information
Categories
(Directory :: LDAP C SDK, defect)
Directory
LDAP C SDK
Tracking
(Not tracked)
ASSIGNED
5.14
People
(Reporter: rmegginson0224, Assigned: mcs)
Details
Attachments
(2 files)
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) Build Identifier: no user agent Some directory servers support a new control called Get Effective Rights which allows a user (typically an administrative user) to see what access rights would apply to another user, without having to BIND as that user and attempt the operation. The control is defined in this internet draft: http://www.ietf.org/proceedings/01dec/I-D/draft-ietf-ldapext-acl-model-08.txt The SDK should be able to understand the response control, and the ldapsearch program should be able to print out the results returned from the control. It would be nice to add another command line option, but this is not strictly necessary since the current -J option allows the user to pass in arbitrary controls by OID. Reproducible: Always Steps to Reproduce: 1. 2. 3.
Assignee | ||
Comment 1•21 years ago
|
||
Which LDAP servers support this control? Sun does, right?
Assignee | ||
Updated•21 years ago
|
Target Milestone: --- → 5.14
Reporter | ||
Comment 2•21 years ago
|
||
Only Sun DS 5.2, AFAIK.
Comment 3•21 years ago
|
||
The proposal is for handling the get-effective-rights response only, not the request. It has been tested against the soon-to-be-released Netscape DS 6.21.
Comment 4•21 years ago
|
||
Assignee | ||
Comment 5•21 years ago
|
||
My biggest concern is that the document that defines this control is dead (as far as I can tell). Do Sun and Netscape both implement this exactly the same way? Is there a specification anywhere. Your eexample that shows using the control does not match what is described in http://www.ietf.org/proceedings/01dec/I-D/draft-ietf-ldapext-acl-model-08.txt; for example the control values are described as BER encoded sequences but you just use strings. I also have some minor comments on the proposed patch: 1) If at all possible, let's use write_string_attr_value() to output the value in ldapsearch, not printf(). Do the return (string) values really have LDIF-like attribute: value embedded in them? Not very pretty in my opinion. 2) The LDAP C SDK code using tabstop=8. Please take that into account when making changes. 3) Let's put underscores in the control OID macro, e.g., #define LDAP_CONTROL_GET_EFFECTIVE_RIGHTS "1.3.6.1.4.1.42.2.27.9.5.2" Or did Sun ship and LDAP C SDK with out underscores in the name?
Status: NEW → ASSIGNED
Comment 6•20 years ago
|
||
Hi Mark, thanks for your comments. How do you tell that a draft is dead? Next time I hope I can realize it sooner. You're right that my example doesn't match the spec since the control value is not BER encoded. This was done on purpose to give users some convenience in using -J option. Users can also give BER string if they choose so. Sun added a -c option in their ldapsearch to take plain dnAuthzId so their users don't have to know anything about BER encoding. Some new changes were made to Netscape DS so that it's no longer relying on the client side to interpret the strings of the effective rights. The rights are now excluded from the response control and appended to the stream of the search result sent back to the clients. Thus clients can see them as normal attributes. This might be the spec's intend as well, though I found the spec is not very clear about this. Netscape DS also renamed the macro of the OID based on your advice 3). Sun uses LDAP_CONTROL_GET_EFFECTIVE_RIGHTS_REQUEST but I didn't see why we need to distinguish the _REQUEST and the _RESPONSE in the control name. Can't we distinguish the two from the context or which control queue they are on?
Comment 7•20 years ago
|
||
This issue is resolved, right?
Assignee | ||
Comment 8•20 years ago
|
||
No code landed for this yet.
You need to log in
before you can comment on or make changes to this bug.
Description
•