From 285930cbcc3e2074ed7fe78a47aec55e49749953 Mon Sep 17 00:00:00 2001 From: Arthur de Jong Date: Sat, 6 Jun 2009 20:46:33 +0000 Subject: 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 --- README | 28 +++++++++++++++++++--------- 1 file changed, 19 insertions(+), 9 deletions(-) (limited to 'README') 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 -- cgit v1.2.3