[Date Prev][Date Next] [Chronological] [Thread] [Top]

back-passwd (Was: ITS#40 )

I've committed a set of changes based upon your patches.
The scope handling needed some minor improvement.  I
also modified the codes to use dn_*() and rdn_attr_*()
routines and fix a couple of minor bugs.

>Addressing the problems in the original message:
>1) The DN returned is of the form cn=pw_name, SUFFIX.
	I left DN uid=pw_name.
	The rdn attribute type could be configuration item.

>2) The uid attribute is gone.
	Added it back in.  Also assigned cn=pw_name and sn=pw_name
	because cn,sn are both required attributes of person.

>3) The GECOS field is parsed for cn and sn fields. The BSD usage of '&'
>in the GECOS field is recognized. The cn is terminated at the
>first ',' in the GECOS. The sn is only shown if there is a space in the cn,
>in which case the tail of the cn is used as the sn.
	Left this alone.

>For the suggested changes:
>1) I left the objectclass as person. Perhaps posixAccount would be more
	person is painful as it requires cn & sn attributes.
	objectclass(es) could be a configuration item.

> this is only a demo backend.

That's very true.  It also serves as a "get your feet wet" backend
for would-be slapd hackers.

>2) The DN is hardcoded to use cn=
	See above.
>3&4) The full name is processed, the description attribute contains the raw
>contents of the GECOS field.
	Looks good.
>5) There isn't enough agreement on usage of the rest of the GECOS field to
>warrant this.
>6) didn't do it.
>7) didn't do it.
>Some other fixes: I added an entry for the base of the backend itself, which
>is just an organizationalUnit. Also, I added a check to prevent searches
>within this backend from nesting endlessly. (E.g., in the original code,
>given the backend at ou=passwd; a onelevel or subtree search based at
>cn=root,ou=passwd would return the same results as a onelevel or subtree
>search based at ou=passwd. And so on and so on...)

I modified the code such that a one/sub search at the suffix would
return the suffix entry and passwd entries (if they passed the filter).
I also added some additional error handling.

Also, as base and suffix are normalized (uppercase) DNs, I tolowerred
the username during a 'base' search for an entry.

And I added 'make passwd' in ldap/tests.  For now, it just does
a few searches using the local password file.  See test-db/ldapsearch.out
for results.  Test inputs (data/passwd) and outputs (data/passwd.out)
need to be written.

	- Kurt