3.0.11 Always escaping = and ,

[Peter Lambrechtsen]

On Tue, Mar 1, 2016 at 5:02 AM, Arran Cudbard-Bell <
a.cudbardb at freeradius.org> wrote:

>
> >> Any way to stop the xlat from expanding the value, I've tried unescape
> and
> >> a number of different options without success?
>
> Yes, create the entire DN as the value of an attribute and use &<attribute>
> (with no quotes) as the configuration item in the LDAP module.
>

Nope, that doesn't work either on 3.0.11 :(

(0)       update request {
(0)         TNZ-BaseDN := "ou=Realms,ou=Proxy,o=Identities"
(0)       } # update request = noop
rlm_ldap (ldap.nodeauth): Reserved connection (0)
(0) ldap.nodeauth: EXPAND (cn=%{Realm})
(0) ldap.nodeauth:    --> (cn=m2m)
(0) ldap.nodeauth: Performing search in "&TNZ-BaseDN" with filter
"(cn=m2m)", scope "sub"
(0) ldap.nodeauth: Waiting for search result...
(0) ldap.nodeauth: ERROR: Failed performing search: Invalid DN syntax
rlm_ldap (ldap.nodeauth): Released connection (0)



> String escaping is (and can only be) applied to xlat expansions.
>
> The taint functionality Alan described would be useful for making this
> safer.
>

I've used custom defined VSAs in either the request or control as variables
that get leveraged but modules further down the logic path in the code.

Unless there is some other way to have a variable that isn't a VSA in
Request or Control can be passed into various modules (ldap, sql, perl,
files) and used within those modules easily. I haven't seen a way to easily
do that without poking the value I want into a temp VSA.

In this case I was hoping to be clever re-using a single LDAP module with
it's threads and set the required Variable / VSA before calling the LDAP
module I need. This is because I have a fairly complex structure in LDAP,
and have noticed an issue where having a duplicate CN in two different
parts of the hierarchy for various reasons on 3.0.10 caused a segfault, now
in 3.0.11 it just returns a fail which is fine.

So if I could set the base DN to only look into the applicable OU then I
wouldn't need multiple modules depending on the user type.

I had hoped to have in the LDAP module:

base_dn = "%{TNZ-BaseDN}ou=Proxy,o=identities"

And then if I needed to set any value for the specific Base DN I needed I
would just update request TNZ-BaseDN and set it to what I want.

This works for me as the value doesn't need to be escaped

base_dn = "ou=%{TNZ-BaseDN},ou=Proxy,o=identities"

But means I always need to have the BaseDN set to something and I can't
leverage some of the hierarchy I have already built and may need to
redesign some of my LDAP structure. No biggie, just a slight change to my
design.