[Dovecot] Ignored proxy_maybe var and no local login when "host = Proxy FQDN"
Hi help is preciated,
PROBLEM
The dovecot-ldap.conf of "proxy server A" is working when the "host" attribute is the FQDN of other server:
pass_attrs = uid=user,userPassword={SSHA}password,
=proxy_maybe=,maildrop=host,=port=143,=destuser=%u,=starttls=any-cert
pass_filter = (&(objectClass=posixAccount)(uid=%u))
CASES
When the "host" attribute is the "FQDN of server A" dovecot imap-login start and infinite loop which swallow all RAM, and process are showing many connections although is just 1 test user connected. It seems that connections are infinitely proxified to it self.
When the "host" attribute is the "IP of server A" dovecot imap-login works OK, login the user locally in the server A.
I include debug message int the source of "dovecot-2.0.11/src/auth/auth-request.c" which appears:
Mar 25 14:10:49 debian dovecot: auth: Debug: ldap(steran,172.26.98.85): result: uid(user)=steran maildrop(host)=smtp2.tsj-dem.gob.ve Mar 25 14:10:49 debian dovecot: auth: Debug: BROKEN SETUP
The modifications appears here and reveals problems with the call to net_addr2ip(host, &ip) in auth_request_proxy_is_self:
static bool auth_request_proxy_is_self(struct auth_request *request) { const char *const *tmp, *host = NULL, *port = NULL, *destuser = NULL; struct ip_addr ip;
tmp = auth_stream_split(request->extra_fields);
for (; *tmp != NULL; tmp++) {
if (strncmp(*tmp, "host=", 5) == 0)
host = *tmp + 5;
else if (strncmp(*tmp, "port=", 5) == 0)
port = *tmp + 5;
if (strncmp(*tmp, "destuser=", 9) == 0)
destuser = *tmp + 9;
}
if (host == NULL || net_addr2ip(host, &ip) < 0) {
/* broken setup */
T_BEGIN {
i_debug("BROKEN SETUP %s", host);
} T_END;
return FALSE;
}
if (!net_ip_compare(&ip, &request->local_ip)){
T_BEGIN {
i_debug("%s", "IPS NOT EQUAL");
}T_END;
return FALSE;
}
if (port != NULL && !str_uint_equals(port, request->local_port)){
T_BEGIN {
i_debug("%s", "PORTS DIFFERENT");
} T_END;
return FALSE;
}
return destuser == NULL ||
strcmp(destuser, request->original_username) == 0;
}
-- "You don't know where your shadow will fall", Somebody.-
Olaf Reitmaier Veracierta <olafrv@gmail.com>
http://www.olafrv.com
On Fri, 2011-03-25 at 17:56 -0430, Olaf Reitmaier Veracierta wrote:
The dovecot-ldap.conf of "proxy server A" is working when the "host" attribute is the FQDN of other server:
pass_attrs = uid=user,userPassword={SSHA}password,
=proxy_maybe=,maildrop=host,=port=143,=destuser=%u,=starttls=any-cert pass_filter = (&(objectClass=posixAccount)(uid=%u)) .. The modifications appears here and reveals problems with the call to net_addr2ip(host, &ip) in auth_request_proxy_is_self:
Yeah. The main problem is that this loop detection code is in auth process, which won't be doing any DNS lookups. I already once tried moving it to login process code where it belongs to, but I failed back then. Hmm. Maybe because request->original_username isn't available to login processes. But I guess it could be set back.
Anyway, I think it's a bit too dangerous to go change this logic too much for v2.0. For v2.1 I guess this could be fixed (and you could easily backport that patch then).
On Fri, Mar 25, 2011 at 7:05 PM, Timo Sirainen <tss@iki.fi> wrote:
On Fri, 2011-03-25 at 17:56 -0430, Olaf Reitmaier Veracierta wrote:
The dovecot-ldap.conf of "proxy server A" is working when the "host" attribute is the FQDN of other server:
pass_attrs = uid=user,userPassword={SSHA}password,
=proxy_maybe=,maildrop=host,=port=143,=destuser=%u,=starttls=any-cert pass_filter = (&(objectClass=posixAccount)(uid=%u)) .. The modifications appears here and reveals problems with the call to net_addr2ip(host, &ip) in auth_request_proxy_is_self:Yeah. The main problem is that this loop detection code is in auth process, which won't be doing any DNS lookups. I already once tried moving it to login process code where it belongs to, but I failed back then. Hmm. Maybe because request->original_username isn't available to login processes. But I guess it could be set back.
Ok...
I will use the IP address in the the maildrop (host) field of my user's LDAP entries.
Anyway, I think it's a bit too dangerous to go change this logic too much for v2.0. For v2.1 I guess this could be fixed (and you could easily backport that patch then).
Well, although there is no solution right now for the problem, your reply was really fast and helpful.
Thank you,
Best regards.-
-- "You don't know where your shadow will fall", Somebody.-
Olaf Reitmaier Veracierta <olafrv@gmail.com>
http://www.olafrv.com
participants (2)
-
Olaf Reitmaier Veracierta
-
Timo Sirainen