[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: (ITS#3472) return code should be 32 when no access to object
- To: quanah@stanford.edu
- Subject: Re: (ITS#3472) return code should be 32 when no access to object
- From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
- Date: Fri, 07 Jan 2005 20:38:25 -0800
- Cc: openldap-devel@OpenLDAP.org
- In-reply-to: <200501080059.j080xbi0027275@boole.openldap.org>
- References: <200501080059.j080xbi0027275@boole.openldap.org>
[Redirected to -devel for discussion]
At present, "none" implies "disclose on error". It really should
be "don't disclose on error". We should have another level,
"disclose", which means "disclose on error".
So,
access to *
by dn=cn=Manager
by self read
by users disclose
by anonymous none
First and second "by" clause as is now. Third means that users
who attempt to access some object will be told "access denied",
with a matchedDN, etc.. (That is, just like today's "none").
Last means "don't disclose on error", hence noSuchObject is
returned even if the entry exists, and matchedDN will be empty,
etc..
I've added the basic parse code for "disclose" and "+d", appreciate
help in implementing this.
I also added basic parse code for "manage" and "+m". This is
intended to be used for manage DSA IT authorization (e.g.,
permission to override a DIT constraint, such as
noUserModification). More on this later.
Kurt
At 04:59 PM 1/7/2005, quanah@stanford.edu wrote:
>Full_Name: Quanah Gibson-mount
>Version: 2.2.20
>OS: Solaris 8
>URL: ftp://ftp.openldap.org/incoming/
>Submission from: (NULL) (171.66.182.82)
>
>
>This is a feature enhancement ITS.
>
>Currently, when someone tries to access an entry that they do not have access
>to, OpenLAP returns err=0. If they try to access an an entry that doesn't
>exist, they get err=32, no such object.
>
>>From a security standpoint, I would assume that in the first case, the client
>should really get err=32, no such object, to potentially prevent malicious
>people from gathering what entry actually exist in your server.
>
>Kind of an example on this, is stanford has its account tree, in the form:
>
>uid=XXXX,cn=accounts,dc=stanford,dc=edu. All UID's are emailable (uid=quanah,
>quanah@stanford.edu), etc. So the potential is there for an intelligent spammer
>to test various uid=XXXX values and see whether they get err=32 or err=0, and
>build up a list of valid accounts to spam.