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

Re: siffixAlias



As this is primarily a development issue, please redirect
any discussion to openldap-devel@openldap.org.  Thanks.
        Kurt

At 10:17 AM 12/4/00 +0100, Pierangelo Masarati wrote:
>Hi.
>
>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
>suffix
>has already been appended to the list of legal backend suffixes the test
>fails;
>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
>file,
>but the "suffixAlias" directive fails if it comes after the extra suffix
>lines.
>
>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
>suffixes.
>
>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