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



I submitted to OpenLDAP a patch for default suffix handling
(ITS #723, incorporated in 2.X).
By digging into the code, I found out that the same result could
have been obtained by using the lines

# inside database definition
suffix              "dc=my, dc=org"
suffixAlias    ""    "dc=my, dc=org"
suffix              ""

I wasn't able to obtain this result previously because I was
erroneously writing

suffix              "dc=my, dc=org"
suffix              ""
suffixAlias    ""    "dc=my, dc=org"

and, since the code that reads the "suffixAlias" card in
servers/slapd/config.c performs overconstraining, brain-damaged sanity
checks simply resulting in a
warning, it didn't work as expected.
In fact, to check if the aliasing suffix had been already defined, it
uses the
select_backend function from servers/slapd/backend.c; if the aliasing
has already been appended to the list of legal backend suffixes the test
however, if the aliasing suffix is not appended to the backend legal
suffix list,
there is no way the select_backend routine will ever succeed when a
request with
the aliasing suffix come in! So all the suffix_alias calls

grep suffix_alias *.c
bind.c:         ndn = suffix_alias( be, ndn );
compare.c:      ndn = suffix_alias( be, ndn );
delete.c:       ndn = suffix_alias( be, ndn );
modify.c:       ndn = suffix_alias( be, ndn );
modrdn.c:               nnewSuperior = suffix_alias( be, nnewSuperior );

modrdn.c:       ndn = suffix_alias( be, ndn );
saslauthz.c:    searchbase = suffix_alias( be, searchbase );
saslauthz.c:    searchbase = suffix_alias( be, searchbase );
search.c:       nbase = suffix_alias( be, nbase );

are plainly useless if there is no "suffix <aliasingSuffix>" in the conf
but the "suffixAlias" directive fails if it comes after the extra suffix

The checks (today's devel branch) should correctly read

--- config.c.orig       Mon Dec  4 09:28:08 2000
+++ config.c    Mon Dec  4 09:58:24 2000
@@ -471,16 +471,16 @@
                                        "%s: line %d: suffixAlias line"
                                        " must appear inside a database definition (ignored)\n",
                                        fname, lineno, 0 );
-                       } else if ( (tmp_be = select_backend( cargv[1], 0 )) != NULL ) {
+                       } else if ( (tmp_be = select_backend( cargv[1], 0 )) != be ) {
                                Debug( LDAP_DEBUG_ANY,
                                        "%s: line %d: suffixAlias served by"
-                                       "  a preceeding backend \"%s\" (ignored)\n",
+                                       " a preceeding backend \"%s\" (ignored)\n",
                                        fname, lineno, tmp_be->be_suffix[0] );

-                       } else if ( (tmp_be = select_backend( cargv[2], 0 )) != NULL ) {
+                       } else if ( (tmp_be = select_backend( cargv[2], 0 )) != be ) {
                                Debug( LDAP_DEBUG_ANY,
-                                       "%s: line %d: suffixAlias derefs to differnet backend"
-                                       "  a preceeding backend \"%s\" (ignored)\n",
+                                       "%s: line %d: suffixAlias derefs to"
+                                       " a different backend \"%s\" (ignored)\n",
                                        fname, lineno, tmp_be->be_suffix[0] );

                        } else {

(a couple of typos have also been fixed! ;-)

Finally, a better solution would require the select_backend funtion to
check also
for the aliased suffixes in order to be able to select the proper
backend even when
it is accessed in aliased form, without the need to add the aliased
suffixes as extra

What I'm wondering about is: what's exactly the meaning of the
suffixAlias stuff?
Is it intended as I'm using it - i.e. to allow requests with a different
base to be
satisfied - or does it have other purposes? In my opinion, with little
effort we could
exploit it to implement a ldap reverse proxy for any backend, i.e. a
server that accepts
requests for a certain base, satisfies them by calling a backend with a
different base
and the masquerades the result by changing the base of each dn with the
aliased suffix
the request came in with. This could be particularly useful in hiding
existing, legacy
distributed directory servers in a big organization behind a common
search base,
or in allowing access to an existing server behind a firewall with a
different, legal
base by means of the back-ldap backend.

If you find it interesting, I'd be pleased to contribute.

Pierangelo Masarati
SysNet s.n.c. <ando@sys-net.it>

Dr. Pierangelo Masarati               | voice: +39 02 2399 8365
Dip. Ing. Aerospaziale                | fax:   +39 02 2399 8334
Politecnico di Milano                 | mailto:masarati@aero.polimi.it
via La Masa 34, 20156 Milano, Italy   | http://www.aero.polimi.it/~masarati