implement case-sensitive filtering for group, netgroup, passwd, protocols, rpc, services and shadow lookups

git-svn-id: http://arthurdejong.org/svn/nss-pam-ldapd/nss-ldapd@934 ef36b2f9-881f-0410-afb5-c4e39611909c

1 files changed, 19 insertions, 9 deletions

diff --git a/README b/README
index 79d899a..44214b5 100644
--- a/README
+++ b/README
@@ -313,8 +313,8 @@ the uid attribute.
 
 If the DN value already contains a uid value (e.g. uid=arthur, dc=example,
 dc=com) the lookup is skipped and the value from the DN is used. A cache is
-maintained that holds on to DN to uid translations for 15 minutes
-(see DN2UID_CACHE_TIMEOUT in nslcd/passwd.c).
+maintained that holds on to DN to uid translations for 15 minutes (see
+DN2UID_CACHE_TIMEOUT in nslcd/passwd.c).
 
 In all cases, users that are specified as member multiple times are returned
 only once.
@@ -323,15 +323,25 @@ Currently, having nested groups by uniqueMember values pointing to other
 groups, as well as the memberOf attribute in posixAccount entries are
 unsupported.
 
-
-MISC NOTES
-==========
+case sensitivity
+----------------
 
 Most values in the NSS databases are considered case-sensitive (e.g. the user
-"Foo" is a different user from "foo"). Values in an LDAP database are however
-case-insensitive. This may cause problems in some corner cases, especially
-when nscd is used for caching. For example, when doing a lookup for the user
-"Foo" the user "foo" will be returned if it exists in the database.
+"Foo" is a different user from the user "foo"). Values in an LDAP database are
+however cosidered case-insensitive. nss-ldapd tries to solve this problem by
+adding an extra filtering layer and ensure that e.g. when looking for the user
+"foo" it will not return a user "Foo" that is found in LDAP.
+
+For the group, netgroup, passwd, protocols, rpc, services and shadow maps the
+matches will be checked case-sensitively and for aliases, ethers, hosts and
+networks matches will be case-insensitive (this seems to be what Glibc is
+doing currently with flat files). Only searching for groups by member the
+username matching is done case-insensitive. Note that in all cases the
+case-use in the LDAP directory is returned.
+
+Note however that having entries that only differ in case is a bad idea and
+will likely get you in trouble. One example of such a problem is that the DN
+uid=test,dc=example,dc=com is the same as uid=TEST,dc=example,dc=com.
 
 
 REPORTING BUGS