On Mon, 2010-12-20 at 15:05 +0100, Raphaël Hertzog wrote: > nslcd refuses to return group names which contain a tilde. It does this on > the basis that it's not part of the portable filename character set: > http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_276 > > I would argue that it's not really nslcd's job to validate what's in the > directory and that it's up to the user to decide whether he cares about > the portability of his user/group names.
The check is currently used for two things: - filtering data returned from LDAP (mostly to check if reasonable data is returned and to avoid confusion over group members that are specified as DN) - filtering requests from applications that will be translated into LDAP searches Since user and group information is rather sensitive (incorrect data can have security consequences) I would prefer to have strict-as-reasonable checks for users and groups to avoid surprises. A lot of applications make (incorrect) assumptions on user names and can behave strangely if they are different than expected. Also, since nslcd is often indirectly accessible from outside the machine (think http://host/~user requests, SSH probes or u...@host emails) some care is in order. In that regard things can be improved further in nslcd (e.g. checks that returned full names or home directories are not random binary data). > You have already added exceptions by allowing "$" and I would like to ask > you to add another exception for "~". Since ~ is used by shells (and other applications) to expand user names to user home directories I think it will be confusing to allow it as a first character, but for other places I don't see a problem. Is that a problem for your configuration? > But you should probably revisit the problem as a whole. > > Good programming principles is to be tolerant in what you read but be > strict in what you send. By that I mean that it's not really nslcd's job > to impose supplementary restrictions that are not needed. Or at least > those restrictions should be configurable so that they can be disabled. In principle, I agree. The issue at hand is however that data that appears to be invalid should not be passed along since there may be security implications. Perhaps it is a good idea to rework the username (and groupname) check and make the check itself be configurable (perhaps using a regexp in the configuration file). Patches for this are most welcome ;) Anyway, thanks for bringing this up. -- -- arthur - adej...@debian.org - http://people.debian.org/~adejong --
signature.asc
Description: This is a digitally signed message part
