https://bugs.exim.org/show_bug.cgi?id=2817
Bug ID: 2817
Summary: readconf authenticator confusion
Product: Exim
Version: 4.95
Hardware: x86
OS: Linux
Status: NEW
Severity: bug
Priority: medium
Component: SMTP Authentication
Assignee: jgh146exb@???
Reporter: wbreyha@???
CC: exim-dev@???
I detected some oddities trying to use cyrus_sasl (server) and gsasl
(client) in parallel.
Background: I'm using cyrus-imapd with lmtpd and tried to use SCRAM-SHA-1
with exim as client. SHA-1 because it's CentOS 7 which has no SHA-256+ support.
I already had cyrus-sasl active for SMTP AUTH since I'm using it with
cyrus-imapd as well.
The server authenticator I used was:
sasl_scram_sha1:
driver = cyrus_sasl
public_name = SCRAM-SHA-1
server_hostname = $smtp_active_hostname
server_advertise_condition = ${if eq{$tls_in_cipher}{}{no}{yes}}
server_set_id = $auth1
Then I compiled Exim with gsasl support included and added
lmtpscram:
driver = gsasl
public_name = SCRAM-SHA-1
client_username = xxxxxx
client_password = xxxxxx
Exim immediately complained about the authenticator config with:
[1\2] 2021-10-10 02:26:08 Exim configuration error:
[2/2] two client authenticators (lmtpscram and sasl_scram_sha1) have the
same public name (SCRAM-SHA-1)
First of all I was wondering why it complained about "two clients" and
found the cause in readconf.c:4191
for (auth_instance * bu = au->next; bu; bu = bu->next)
if (strcmpic(au->public_name, bu->public_name) == 0)
if ((au->client && bu->client) || (au->server && bu->server))
log_write(0, LOG_PANIC_DIE|LOG_CONFIG, "two %s authenticators "
"(%s and %s) have the same public name (%s)",
au->client ? US"client" : US"server", au->name, bu->name,
au->public_name);
The part
au->client ? US"client" : US"server"
alwasy returns "client" as soon as a client part is defined even if the
conflict is on the server side... which is the case in my example. I think
the fix is easy by using:
(au->client && bu->client) ? US"client" : US"server"
here as well.
------ I will file another bug report for the following part
The conflict on server side is caused by gsasl always setting
ablock->server = TRUE;
in gsasl_exim.c:203 and only sets it back to FALSE in some (not met)
conditions. Even
server_condition = false
does not help in this case.
--
You are receiving this mail because:
You are on the CC list for the bug.
