[Date Prev][Date Next]
Re: masking LDAP_SIZELIMIT_EXCEEDED
First off - what you do in the privacy of your own network is your
business, go ahead and write the 8 line overlay if that's what you want.
But realize that the design you have here is an epic security breach
waiting to happen. The purpose of authentication is to unambiguously
identify the client of a service. (And in the case of mutual
authentication, the provider of the service as well.) When you do not
enforce a 1-to-1 mapping of users to login IDs and credentials, you
don't have "authentication" - you just have a guess. I.e., all of your
client software in group (1) below is broken, by definition.
Presumably one reason for giving person2 two separate entries is to give
them two separate roles, two separate classes of authorization. You
might entrust someone with the person2/org2 username and password to
accomplish one set of tasks; if the software accepts that password but
then looks up and uses the person2/org1 privileges instead, you're in
trouble and most of the time you won't even detect when something bad
happens until you read about it in the press.
Aaron Richton wrote:
Hmm, maybe drawing a parallel to an ACL was a bad idea (although this
behavior does sound similar to "disclose" to me because I want to not
expose the truth to some unprivileged clients). The clients I want to
keep in the dark are due to their code path, not because the information
is something that I want to keep from them for privacy/security per se.
We have entries along the lines of:
This is totally valid in our (feel free to call it warped) view of the
world. person2 is indeed the same physical person, but they only
intersect on "uid" from the directory perspective. Very notably,
person2@Org1 and person2@Org2 have different userPassword attributes.
I'm sure this all sounds slightly ridiculous, but it actually works
quite well. It makes things particularly easy for administrators of
systems in either Org1 or Org2. The exception is on queries that span
Org*. We've seen two basic client behaviors with off-the-shelf software:
1. Search, and use the first candidate entry that's returned. Our users
hae been trained that "Org1" is the most important and they should use
that password/expect those attributes on systems that span units.
2. Search, and error out since multiple candidates are returned.
I don't necessarily think there's anything wrong with (2), but it causes
my example "person2" to not get access. What I'd like is to mimic (1).
I've been patching client software to that behavior, but it seems that
there's a lot of (2) out there. So I'm looking for something server-side
to fix this "permanently". If I set a sizelimit of 1, then only
will be returned on a '(uid=person2)' query. The problem is that the
return code is not LDAP_SUCCESS, so I error out on that issue. If I mask
the exceeded result, then the (2) clients will be blissfully ignorant
that person2 spans multiple entries, and grant access under the Org1
candidate dn (which is what I want).
On Thu, 8 Mar 2007, Howard Chu wrote:
Aaron Richton wrote:
I've found a situation similar to what I believe inspired "disclose"
ACLs, in which giving out the return value of LDAP_SIZELIMIT_EXCEEDED
is telling clients something that I don't want them to know (i.e.
"keep digging.") I'd like to just throw away the code and change it
to LDAP_SUCCESS. Can anybody think of a way to do this (slapo-retcode
comes to mind, but I can't see how it would work on these very
non-dynamic entries) or should I just write an eight line overlay?
Is this something that enough people want that there should be, say,
a "silent" option to the limits directive?
This seems like a pointless option. If I do a search for (cn>=a) and
get 500 entries returned, and another search for (cn>=b) and still get
500 entries returned, then it's obvious there are more entries out
there even if you mask the result code. The "disclose" feature of ACLs
is a real security measure, because it prevents you from seeing that
which you could not see by any means. What you're proposing here is
not; the information you're hiding can still be discovered by other
legitimate mechanisms. It is easily circumvented and it's contrary to
the specification of the Directory System models.
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc
Chief Architect, OpenLDAP http://www.openldap.org/project/