Debugging realms w/ cyrus-imapd

Hi,

I'm using cyrus-imapd 4.6.6 and cyrus-sasl-2.1.28 on a Fedora 37 server.

My authentication is done with sasldb (directly, no PAM).

And I created my users as:

echo "password" | saslpasswd2 -p -c -u mail username


But I don't see a difference between creating users this way, and creating =
them with "-a mail" instead of "-u mail" when I dump the sasldb2.

And indeed, "testsaslauthd" succeeds either way... as long as I don't pass =
in an explicit realm, which is confusing... because one isn't present if I =
just do "testsaslauthd -u username -p password" (which succeeds).

I'm using:

sasl_pwcheck_method: saslauthd
sasl_mech_list: CRAM-MD6 DIGEST-MD5

Users don't have local accounts, so all username/password credentials come =
from here.  The realm/appname is "mail" so I can use sasldb for other servi=
ces, while keeping credentials isolated in their own [service] universe.

The saslauthd.service is running as:

/usr/sbin/saslauthd -m /run/saslauthd -a sasldb -r mail

per "ps".  Although... that means I can only authenticate for credentials i=
n the "mail" universe, so maybe that's not good after all.

So I'll drop "-r mail" from the "saslauthd" invocation, but go back to "tes=
tsaslauthd -u username -p password -r mail" and that seems to work well eno=
ugh.

The MS (Cyrus message store, i.e. imap server) host is called "mail.redfish=
-solutions.com".  But when I try to authenticate, I get:

philipp64: Jun 15 16:30:08 mail cyrus/imaps[50815]: badlogin: macbook3-4.re=
dfish-solutions.com [192.168.8.12] CRAM-MD5 (-notset-) [SASL(-13): user not=
 found: user: [email protected] property: cmusaslsecretCR=
AM-MD5 not found in /etc/sasl2/sasldb2]

So I tried to override the "domain" that gets substituted in as the "realm"=
 via:

defaultdomain: mail

in /etc/imapd.conf and restarted the service. No change, and still the same=
 failure message.  Looking through source code, it seems that "defaultdomai=
n" doesn't do anything unless "virtdomains: true" is also set.  Whaaa....t?=
  Starting to get the feeling that "domain" and "realm" are really blurred =
here.

Seems I have to explicitly do "hostname mail" to get authentication to work=
... which I don't understand.  I should be able to move this service freely=
 between hosts, without it being tied to the hostname.

And indeed, I should be able to control all aspects of configuration throug=
h explicit settings, right?  Nothing about the run-time environment should =
be bleeding through if I try to override it... yet that's what happens with=
 the hostname.

And it seems that "real" and "gethostname()" are also blurred here.

It was suggested that instead of "defaultdomain" I try "servername" instead=
, and that seems to work.

But this is getting really confusing.

Is there a railroad diagram that explains all the possible values that get =
used by cyrus-imapd to populate the "realm" field if one isn't given?  And =
in what order?

I started to submit a patch for supporting a "defaultrealm" but on reflecti=
on, this seems to add more complexity to an already confusing and unintuiti=
ve situation.

Maybe a better strategy is (1) require explicitly configuring the correct v=
alue to use, or (2) limiting the number of external values that can implici=
tly get filled in as the default.

But wait, if I change the hostname back to "mail.redfish-solutions.com" but=
 add the magic incantation:

servername: mail

Things work ... as best as I can tell.

Do they?  Let's peek at the dialog over the IMAP/S socket between client an=
d server:

* OK [CAPABILITY IMAP4rev1 LITERAL+ ID ENABLE AUTH=3DCRAM-MD5 AUTH=3DDIGEST=
-MD5 SASL-IR] mail Cyrus IMAP 3.4.4-2.fc37 Fedora server ready

And... hell and damnation.  The host banner is presenting as "mail" and not=
 the FQDN.

So close... almost... had... it... perfect!

Back to the drawing board.  Sifting through the source code, I see this:

https://github.com/cyrusimap/cyrus-sasl/blob/master/plugins/sasldb.c#L233-L=
237

    if(sparams->user_realm) {
        user_realm =3D sparams->user_realm;
    } else {
        user_realm =3D sparams->serverFQDN;
    }

And yes, that's in SASL, not the IMAP code of the server.  That seems just =
plain wrong.  If we're not passed all the parameters we need, take a guess =
at them?  Not good behavior for a library.  And plugins/digestmd5.c and plu=
gins/sql.c make a similar assumption, which means that there's also duplica=
tion going on.

Seeing other stuff that's questionable in the code, like:

https://github.com/cyrusimap/cyrus-sasl/blob/master/plugins/digestmd5.c#L42=
94

                               params->serverFQDN ? params->serverFQDN : NU=
LL);

which is functionally equivalent to:

                               params->serverFQDN);

unless I'm missing something.

Sorry if I sound grouchy.  I've put a lot of time into trying to debug this=
 and I've not figured out an adequate fix, as you can see above.

I'm happy to contribute a patch or two to improve things, but first I'd hav=
e to understand all the ways that the user realm can be populated, and... h=
ow it *should* be populated because implicitly defaulting to various other =
things seems perilous (it was for me when I changed my hostname and authent=
ication started failing).

-Philip



------------------------------------------
Cyrus: SASL
Permalink: https://cyrus.topicbox.com/groups/sasl/T3f1dd03bb4edc239-Maeee09=
dabf84c92b282feb6f
Delivery options: https://cyrus.topicbox.com/groups/sasl/subscription