236492 - SDK should handle and print out Get Effective Rights information

Status: RESOLVED INCOMPLETE

(Directory Graveyard :: LDAP C SDK, defect)

Description

[Rich Megginson]

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.

Comment 1

[Mark Smith [:mcs]]

Which LDAP servers support this control?  Sun does, right?

Comment 2

[Rich Megginson]

Only Sun DS 5.2, AFAIK.

Comment 3

[Kaining Gu]

Attachment: Proposal for ldap-extension.h and ldapsearch.c changes

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

[Kaining Gu]

Attachment: Some ldapsearch test results

Comment 5

[Mark Smith [:mcs]]

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?

Comment 6

[Kaining Gu]

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

[Rich Megginson]

This issue is resolved, right?

Comment 8

[Mark Smith [:mcs]]

No code landed for this yet.