================
Written by Hallvard B. Furuseth and placed into the public domain.
This software is not subject to any license of the University of Oslo.
================
Adapted by Kurt Zeilenga for inclusion in OpenLDAP. My comments are
marked with enclosed with square brackets (e.g. [Kurt's comment] below.
================
If I run ldapmodify & co from a script, I don't want to use '-W password'
because the password shows up in the output of 'ps' for everyone,
and I can't pipe the password to 'ldapmodify -w' because -w uses
getpassphrase() which reads from the tty instead of stdin.
So I added '-y file' which reads the password from file. The programs
exit if the file cannot be read.
[Complete contents of file is used as password. Use:
echo -n "secret" > password
to create a file with "secret" as the password. The -n avoids
adding a newline (which would invalidate the password). Note
that echo is a builtin and hence its arguments are not visible
to 'ps'.]
I changed ldapmodify, ldapmodrdn, ldapdelete, ldapsearch, ldapcompare.
I did not bother to change ldappasswd and ldapwhoami, because they
prompt for many passwords. [I fixed up ldapwhoami.]
Rerun autoconf after applying this patch. [Done.]
Note: I do not know if Windows NT has fstat(), so I set HAVE_FSTAT to
undef in portable.nt. (fstat() is used to warn if the file is publicly
readable or writeable.) [I used fstat() to set the buffer size to
read.]
[Note: using the contents of a file extends the tools to support
passwords which could not normally be provided using getpassphrase()
or via the command line.]
Hallvard B. Furuseth <h.b.furuseth@usit.uio.no>, Aug 2002.
[Kurt D. Zeilenga <kurt@openldap.org>, Aug 2002.]
Now related ITSes need be audited and possibly closed.
Enhancements:
- re-styled code for better readability
- upgraded backend API to reflect recent changes
- LDAP schema is checked when loading SQL/LDAP mapping
- AttributeDescription/ObjectClass pointers used for more efficient
mapping lookup
- bervals used where string length is required often
- atomized write operations by committing at the end of each operation
and defaulting connection closure to rollback
- added LDAP access control to write operations
- fully implemented modrdn (with rdn attrs change, deleteoldrdn,
access check, parent/children check and more)
- added parent access control, children control to delete operation
- added structuralObjectClass operational attribute check and
value return on search
- added hasSubordinate operational attribute on demand
- search limits are appropriately enforced
- function backsql_strcat() has been made more efficient
- concat function has been made configurable by means of a pattern
- added config switches:
- fail_if_no_mapping write operations fail if there is no mapping
- has_ldapinfo_dn_ru overrides autodetect
- concat_pattern a string containing two '?' is used
(note that "?||?" should be more portable
than builtin function "CONCAT(?,?)")
- strcast_func cast of string constants in "SELECT DISTINCT statements (needed by PostgreSQL)
- upper_needs_cast cast the argument of upper when required
(basically when building dn substring queries)
Todo:
- add security checks for SQL statements that can be injected (?)
- re-test with previously supported RDBMs
- replace dn_ru and so with normalized dn (no need for upper() and so
in dn match)
- implement a backsql_normalize() function to replace the upper()
conversion routines
- note that subtree deletion, subtree renaming and so could be easily
implemented (rollback and consistency checks are available :)
- implement "lastmod" and other operational stuff (ldap_entries table ?)
- now all write operations appear to work correctly with PostgeSQL 7.0
- all write operations have been made transactional (atomic writes to
entries are committed separately only in case of complete^1 success
while all other operations are rolled-back by default)
- more cleanup and handling of exceptional conditions
TODO:
- deen to check with different databases and more up to date versions
of both unixODBC and PostgreSQL.
^1: attribute add/modify/delete operations silently succeed if the
appropriate add/delete proc does not exist for each attribute;
this may be correct to hide undesired/unimplemented correspondence
between LDAP and SQL databases; however, a more appropriate
LDAP behavior would be a failure with LDAP_UNAVAILABLE if a
single write operation cannot be executed for such reason
