Re: Postfix+SASL chrooted - out of ideas (SASL_README tweak)
On Fri, Jun 03, 2022 at 03:58:04PM +0200, Matus UHLAR - fantomas wrote: > > On Fri, Jun 03, 2022 at 11:09:08AM +0200, Matus UHLAR - fantomas wrote: > > > this will unpack the tarball in local directory. > > > I use standard debian packages, there's SASL related patch but it doesn't > > > seem to affect this issue > > > > > > https://sources.debian.org/patches/postfix/3.5.6-1/ > > > https://sources.debian.org/patches/postfix/3.5.6-1/07_sasl_config.diff/ > > On 03.06.22 09:27, Viktor Dukhovni wrote: > > The patch introduces a "SASL_CB_GETCONFPATH" callback, that indeed adds > > "/etc/postfix/sasl" to the SASL config search path. This creates two > > conflicting ways to set the location, with the patch likely overriding > > "cyrus_sasl_config_path", and not providing any mechanisms to choose > > alternative locations. > > I have tried with debian 11 and I can confirm this. > Changing cyrus_sasl_config_path did not help and > /etc/postfix/sasl/smtpd.conf was used. That's what I'm seeing too, now. The lesson for me here is not to perform experiments the day after general anaesthetic. :-) cheers, raf
Re: Postfix+SASL chrooted - out of ideas (SASL_README tweak)
On June 3, 2022 3:20:31 PM UTC, Viktor Dukhovni wrote: >On Fri, Jun 03, 2022 at 09:27:15AM -0400, Viktor Dukhovni wrote: >> On Fri, Jun 03, 2022 at 11:09:08AM +0200, Matus UHLAR - fantomas wrote: >> >> > >Also can you "apt-get source postfix", and post a link to the tarball? >> > >> > this will unpack the tarball in local directory. >> > I use standard debian packages, there's SASL related patch but it doesn't >> > seem to affect this issue >> > >> > https://sources.debian.org/patches/postfix/3.5.6-1/ >> > https://sources.debian.org/patches/postfix/3.5.6-1/07_sasl_config.diff/ >> >> The patch introduces a "SASL_CB_GETCONFPATH" callback, that indeed adds >> "/etc/postfix/sasl" to the SASL config search path. This creates two >> conflicting ways to set the location, with the patch likely overriding >> "cyrus_sasl_config_path", and not providing any mechanisms to choose >> alternative locations. >> >> This patch is IMHO obsolete and counterproductive, and should be >> deprecated. Debian should take advantage of "cyrus_sasl_config_path", >> possibly with a custom compile-time default, or else just set at >> install, or at upgrade time (if not already set, and the previous >> Postfix version contains the patch). > >I am also a bit puzzled about memory correctness in this patch. It >allocates the callback data with the Postfix concatenate(), which uses >the Postfix mymalloc(), but if/when SASL ever frees the value, the docs >say it is freed with the C library free(), unless the application >configures a different "free_t" function, which I believe is not the >case. > >All in all, I'd like to see this patch go away. I looked and the patch is unchanged from before I got involved in Postfix maintenance in Debian in 2016. As you no doubt recall, Lamont had a low threshold for adding distribution patches. I think given the existence of cyrus_sasl_config_path this can definitely go away. Scott K
Re: Postfix+SASL chrooted - out of ideas (SASL_README tweak)
On Fri, Jun 03, 2022 at 09:27:15AM -0400, Viktor Dukhovni wrote: > On Fri, Jun 03, 2022 at 11:09:08AM +0200, Matus UHLAR - fantomas wrote: > > > >Also can you "apt-get source postfix", and post a link to the tarball? > > > > this will unpack the tarball in local directory. > > I use standard debian packages, there's SASL related patch but it doesn't > > seem to affect this issue > > > > https://sources.debian.org/patches/postfix/3.5.6-1/ > > https://sources.debian.org/patches/postfix/3.5.6-1/07_sasl_config.diff/ > > The patch introduces a "SASL_CB_GETCONFPATH" callback, that indeed adds > "/etc/postfix/sasl" to the SASL config search path. This creates two > conflicting ways to set the location, with the patch likely overriding > "cyrus_sasl_config_path", and not providing any mechanisms to choose > alternative locations. > > This patch is IMHO obsolete and counterproductive, and should be > deprecated. Debian should take advantage of "cyrus_sasl_config_path", > possibly with a custom compile-time default, or else just set at > install, or at upgrade time (if not already set, and the previous > Postfix version contains the patch). I am also a bit puzzled about memory correctness in this patch. It allocates the callback data with the Postfix concatenate(), which uses the Postfix mymalloc(), but if/when SASL ever frees the value, the docs say it is freed with the C library free(), unless the application configures a different "free_t" function, which I believe is not the case. All in all, I'd like to see this patch go away. -- Viktor.
Re: Postfix+SASL chrooted - out of ideas (SASL_README tweak)
On Fri, Jun 03, 2022 at 09:27:15AM -0400, Viktor Dukhovni wrote: > The only thing to decide is whether the upstream mechanism behind > "cyrus_sasl_config_path" should continue to use the simple > sasl_set_path() API: > > https://github.com/cyrusimap/cyrus-sasl/blob/master/include/sasl.h Correction should be: https://github.com/cyrusimap/cyrus-sasl/blob/master/include/sasl.h#L678-L687 > > or (for no obvious reason) switch to the more elaborate callback used in > the Debian patch: > > > https://github.com/cyrusimap/cyrus-sasl/blob/master/include/sasl.h#L678-L687 Should be: https://github.com/cyrusimap/cyrus-sasl/blob/master/include/sasl.h#L470-L503 > which seems to be more popular, despite the needlessly fancy ceremony. -- Viktor.
Re: Postfix+SASL chrooted - out of ideas (SASL_README tweak)
On Fri, Jun 03, 2022 at 11:09:08AM +0200, Matus UHLAR - fantomas wrote: this will unpack the tarball in local directory. I use standard debian packages, there's SASL related patch but it doesn't seem to affect this issue https://sources.debian.org/patches/postfix/3.5.6-1/ https://sources.debian.org/patches/postfix/3.5.6-1/07_sasl_config.diff/ On 03.06.22 09:27, Viktor Dukhovni wrote: The patch introduces a "SASL_CB_GETCONFPATH" callback, that indeed adds "/etc/postfix/sasl" to the SASL config search path. This creates two conflicting ways to set the location, with the patch likely overriding "cyrus_sasl_config_path", and not providing any mechanisms to choose alternative locations. I have tried with debian 11 and I can confirm this. Changing cyrus_sasl_config_path did not help and /etc/postfix/sasl/smtpd.conf was used. This patch is IMHO obsolete and counterproductive, and should be deprecated. Debian should take advantage of "cyrus_sasl_config_path", possibly with a custom compile-time default, or else just set at install, or at upgrade time (if not already set, and the previous Postfix version contains the patch). debian default of /etc/postfix/sasl would be fine, compatibile with previous versions and both debian and non-debian postfix documentation. The only thing to decide is whether the upstream mechanism behind "cyrus_sasl_config_path" should continue to use the simple sasl_set_path() API: https://github.com/cyrusimap/cyrus-sasl/blob/master/include/sasl.h or (for no obvious reason) switch to the more elaborate callback used in the Debian patch: https://github.com/cyrusimap/cyrus-sasl/blob/master/include/sasl.h#L678-L687 which seems to be more popular, despite the needlessly fancy ceremony. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Despite the cost of living, have you noticed how popular it remains?
Re: Postfix+SASL chrooted - out of ideas (SASL_README tweak)
On Fri, Jun 03, 2022 at 11:09:08AM +0200, Matus UHLAR - fantomas wrote: > >Also can you "apt-get source postfix", and post a link to the tarball? > > this will unpack the tarball in local directory. > I use standard debian packages, there's SASL related patch but it doesn't > seem to affect this issue > > https://sources.debian.org/patches/postfix/3.5.6-1/ > https://sources.debian.org/patches/postfix/3.5.6-1/07_sasl_config.diff/ The patch introduces a "SASL_CB_GETCONFPATH" callback, that indeed adds "/etc/postfix/sasl" to the SASL config search path. This creates two conflicting ways to set the location, with the patch likely overriding "cyrus_sasl_config_path", and not providing any mechanisms to choose alternative locations. This patch is IMHO obsolete and counterproductive, and should be deprecated. Debian should take advantage of "cyrus_sasl_config_path", possibly with a custom compile-time default, or else just set at install, or at upgrade time (if not already set, and the previous Postfix version contains the patch). The only thing to decide is whether the upstream mechanism behind "cyrus_sasl_config_path" should continue to use the simple sasl_set_path() API: https://github.com/cyrusimap/cyrus-sasl/blob/master/include/sasl.h or (for no obvious reason) switch to the more elaborate callback used in the Debian patch: https://github.com/cyrusimap/cyrus-sasl/blob/master/include/sasl.h#L678-L687 which seems to be more popular, despite the needlessly fancy ceremony. -- Viktor.
Re: Postfix+SASL chrooted - out of ideas (SASL_README tweak)
On 02.06.22 08:38, raf wrote: >No. Perhaps in the past, but no longer. I grepped for >/etc/postfix/sasl in every file on a debian11 system >and it didn't appear in libsasl2 or anywhere >interesting. On Thu, Jun 02, 2022 at 03:45:01PM +0200, Matus UHLAR - fantomas wrote: maybe it uses e.g. path like: $config_directory/sasl/$smtpd_sasl_path On 02.06.22 15:21, Viktor Dukhovni wrote: That could happen in main.cf (or a master.cf override), via: cyrus_sasl_config_path = $config_directory/sasl/$smtpd_sasl_path and is most unlikely otherwise. 250-AUTH DIGEST-MD5 NTLM CRAM-MD5 PLAIN LOGIN I have tested it now on debian 11 according to: https://wiki.debian.org/PostfixAndSASL#Implementation_using_Cyrus_SASL version without changing postfix options and I was able to set up sasl authentication. Can you show evidence that: * No component of /etc/postfix/sasl/smtpd.conf is a symlink % ls -ld /etc /etc/postfix /etc/postfix/sasl /etc/postfix/sasl/smtpd.conf drwxr-xr-x 142 root root 12288 Jun 2 15:08 /etc/ drwxr-xr-x 5 root root 4096 Jun 2 15:00 /etc/postfix/ drwxr-xr-x 2 root root 4096 Jun 2 15:35 /etc/postfix/sasl/ -rw-r--r-- 1 root root26 Jun 2 15:35 /etc/postfix/sasl/smtpd.conf * There are no symlinks from /etc/sasl2 ors similar into /etc/postfix/sasl % ls -ld /etc/sasl2 ls: cannot access '/etc/sasl2': No such file or directory * cyrus_sasl_config_path is not set % postconf cyrus_sasl_config_path cyrus_sasl_config_path = % postconf -d cyrus_sasl_config_path cyrus_sasl_config_path = * The /etc/postfix/sasl/smtpd.conf configuration is actually used, e.g. by tweaking the mechanism list to either include or exclude "LOGIN" and that this is reflected in the list of offered AUTH mechanisms in response to EHLO. I tried this before, auth did not work without "pwcheck_method", did without "mech_list" /etc/postfix/sasl/smtpd.conf pwcheck_method: saslauthd mech_list: PLAIN LOGIN What happens when you remove "LOGIN" from this setting? without mech_list line I get: 250-AUTH DIGEST-MD5 NTLM CRAM-MD5 PLAIN LOGIN with the above in mech_list I get: 250-AUTH PLAIN LOGIN postfix restart affects what I see, saslauth restart does not. Also can you "apt-get source postfix", and post a link to the tarball? this will unpack the tarball in local directory. I use standard debian packages, there's SASL related patch but it doesn't seem to affect this issue https://sources.debian.org/patches/postfix/3.5.6-1/ https://sources.debian.org/patches/postfix/3.5.6-1/07_sasl_config.diff/ -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. 10 GOTO 10 : REM (C) Bill Gates 1998, All Rights Reserved!
Re: Postfix+SASL chrooted - out of ideas (SASL_README tweak)
On Thu, Jun 02, 2022 at 03:45:01PM +0200, Matus UHLAR - fantomas wrote: > On 02.06.22 08:38, raf wrote: > >No. Perhaps in the past, but no longer. I grepped for > >/etc/postfix/sasl in every file on a debian11 system > >and it didn't appear in libsasl2 or anywhere > >interesting. > > maybe it uses e.g. path like: > > $config_directory/sasl/$smtpd_sasl_path That could happen in main.cf (or a master.cf override), via: cyrus_sasl_config_path = $config_directory/sasl/$smtpd_sasl_path and is most unlikely otherwise. > I have tested it now on debian 11 according to: > https://wiki.debian.org/PostfixAndSASL#Implementation_using_Cyrus_SASL > > version without changing postfix options > and I was able to set up sasl authentication. Can you show evidence that: * No component of /etc/postfix/sasl/smtpd.conf is a symlink * There are no symlinks from /etc/sasl2 ors similar into /etc/postfix/sasl * cyrus_sasl_config_path is not set * The /etc/postfix/sasl/smtpd.conf configuration is actually used, e.g. by tweaking the mechanism list to either include or exclude "LOGIN" and that this is reflected in the list of offered AUTH mechanisms in response to EHLO. > /etc/postfix/sasl/smtpd.conf > > pwcheck_method: saslauthd > mech_list: PLAIN LOGIN What happens when you remove "LOGIN" from this setting? Also can you "apt-get source postfix", and post a link to the tarball? -- Viktor.
Re: Postfix+SASL chrooted - out of ideas (SASL_README tweak)
On 30/05/22 2:48 pm, raf wrote: > > If set > > +empty (the default value) the search path is the one compiled into the > > +Cyrus SASL library. > > I don't think that's entirely correct. On Debian, for > example, the default value of cyrus_sasl_config_path is > empty, and /etc/postfix/sasl is the directory that is > used. They haven't changed the default value to be > non-empty. It couldn't possibly be that they've compiled it into the cyrus sasl library? > But it does look like it's not the postfix package that > they changed. They changed the sasl2-bin package. > The only executable binary that contains the string > /etc/postfix/sasl is /usr/bin/saslfinger which is > provided by the sasl2-bin package. On Wed, Jun 01, 2022 at 03:56:02PM +1200, Peter wrote: Which suggests that it's been compiled into the cyrus sasl library. On 02.06.22 08:38, raf wrote: No. Perhaps in the past, but no longer. I grepped for /etc/postfix/sasl in every file on a debian11 system and it didn't appear in libsasl2 or anywhere interesting. maybe it uses e.g. path like: $config_directory/sasl/$smtpd_sasl_path I have tested it now on debian 11 according to: https://wiki.debian.org/PostfixAndSASL#Implementation_using_Cyrus_SASL version without changing postfix options and I was able to set up sasl authentication. This was also working on debian 8-10, at least my internal docs also say: adduser postfix sasl /etc/default/saslauthd START=yes OPTIONS="-c -m /var/spool/postfix/var/run/saslauthd" /etc/postfix/sasl/smtpd.conf pwcheck_method: saslauthd mech_list: PLAIN LOGIN dpkg-statoverride --add root sasl 750 /var/spool/postfix/var/run/saslauthd restart saslauthd & postfix It did appear in things like saslfinger and apparmor rules and the postfix package file list and augeas-lenses (a config file parser). But nothing in any libsasl files or postfix files. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Emacs is a complicated operating system without good text editor.
Re: Postfix+SASL chrooted - out of ideas (SASL_README tweak)
On 2/06/22 10:38 am, raf wrote: No. Perhaps in the past, but no longer. I grepped for /etc/postfix/sasl in every file on a debian11 system and it didn't appear in libsasl2 or anywhere interesting. It did appear in things like saslfinger and apparmor rules and the postfix package file list and augeas-lenses (a config file parser). But nothing in any libsasl files or postfix files. Grepping binary files is unreliable. The directory could be composed of multiple strings, could be stored in some way that it doesn't appear as a direct string in the file, could be compressed or even encrypted (not likely but it could be). There's lots of reasons why your grep might not have turned up that string when it is, in fact, compiled in. The only way to know for sure is to pull the debian sources and look through them. Since I'm not an expert in debian packaging I'll leave that to someone who is. Peter
Re: Postfix+SASL chrooted - out of ideas (SASL_README tweak)
On Wed, Jun 01, 2022 at 10:44:51PM +, Scott Kitterman wrote: > >No. Perhaps in the past, but no longer. I grepped for > >/etc/postfix/sasl in every file on a debian11 system > >and it didn't appear in libsasl2 or anywhere > >interesting. It did appear in things like saslfinger > >and apparmor rules and the postfix package file list > >and augeas-lenses (a config file parser). But nothing > >in any libsasl files or postfix files. > > That setting predates my involvement in Debian's postfix maintenance > and since I use Dovecot, it isn't something that I test. It > definitely used to look in /etc/postfix/sasl and I didn't on purpose > change it. I'll add looking into this to my unfortunately long TODO > for Debian postfix. If you, the correct implementation would be at the level of install-time configuration of cyrus_sasl_config_path, to a colon-separated list of directories, perhaps "/etc/postfix/sasl:/etc/sasl2" or the other order, which would retain more compatibility with current behaviour (which looks only in /etc/sasl2). A more *determined* way to look in /etc/postfix/sasl would be a differet compile-time default, and a corresponding change to the postconf(5) manpage documenting the default value. -- Viktor.
Re: Postfix+SASL chrooted - out of ideas (SASL_README tweak)
On Wed, Jun 01, 2022 at 12:03:43AM -0400, Viktor Dukhovni wrote: > On Wed, Jun 01, 2022 at 01:35:56PM +1000, raf wrote: > > > > So what did they do? > > > > > > > $ postconf -d cyrus_sasl_config_path > > > > cyrus_sasl_config_path = > > > > $ postconf cyrus_sasl_config_path > > > > cyrus_sasl_config_path = > > > > $ dpkg-query -S /etc/postfix/sasl > > > > postfix: /etc/postfix/sasl > > > > > > What would make anything look there? > > > > That's a very good question. I have no idea. I searched for > > /etc/postfix/sasl in all files, not just the executable ones, and > > found nothing that explains it. And there are no symlinks to it, > > either. > > > > The Debian Postfix/SASL wiki page definitely indicates that that > > directory is where Postfix's SASL config files go: > > > > https://wiki.debian.org/PostfixAndSASL > > > > I experimented to see if /etc/postfix/sasl is really used, and it > > looks like it isn't. I think that my settings just happen to coincide > > with libsasl2's defaults. > > Now it all begins to make sense, the Debian docs are wrong, and the > search path is the default one (in no-way Postfix-specific) compiled > into Cyrus SASL. > > And if some distro wants a Postfix-specific location, they'd need to > mess around with symlinks or set "cyrus_sasl_config_path" by compiling > in a different default value, or arranging for an override in main.cf at > install time. > > So my suggested doc patch is pretty close, except perhaps that there > are no distros actually doing this??? In which case the doc tweak > can be somewhat different. > > -- > Viktor. That sounds about right. I suspect that Debian did some customization along these lines in the past (at least in Debian7) but they aren't doing it any more (Debian11). I've added instructions to set cyrus_sasl_config_path in that debian Postfix/SASL wiki page, and added a few SASL mechanisms that aren't completely insecure, but it's still not great. I might just add a note there to read Postfix's SASL_README. cheers, raf
Re: Postfix+SASL chrooted - out of ideas (SASL_README tweak)
On June 1, 2022 10:38:55 PM UTC, raf wrote: >On Wed, Jun 01, 2022 at 03:56:02PM +1200, Peter wrote: > >> On 30/05/22 2:48 pm, raf wrote: >> > > If set >> > > +empty (the default value) the search path is the one compiled into the >> > > +Cyrus SASL library. >> > >> > I don't think that's entirely correct. On Debian, for >> > example, the default value of cyrus_sasl_config_path is >> > empty, and /etc/postfix/sasl is the directory that is >> > used. They haven't changed the default value to be >> > non-empty. >> >> It couldn't possibly be that they've compiled it into the cyrus sasl >> library? >> >> > But it does look like it's not the postfix package that >> > they changed. They changed the sasl2-bin package. >> > The only executable binary that contains the string >> > /etc/postfix/sasl is /usr/bin/saslfinger which is >> > provided by the sasl2-bin package. >> >> Which suggests that it's been compiled into the cyrus sasl library. >> >> Peter > >No. Perhaps in the past, but no longer. I grepped for >/etc/postfix/sasl in every file on a debian11 system >and it didn't appear in libsasl2 or anywhere >interesting. It did appear in things like saslfinger >and apparmor rules and the postfix package file list >and augeas-lenses (a config file parser). But nothing >in any libsasl files or postfix files. That setting predates my involvement in Debian's postfix maintenance and since I use Dovecot, it isn't something that I test. It definitely used to look in /etc/postfix/sasl and I didn't on purpose change it. I'll add looking into this to my unfortunately long TODO for Debian postfix. Scott K
Re: Postfix+SASL chrooted - out of ideas (SASL_README tweak)
On Wed, Jun 01, 2022 at 03:56:02PM +1200, Peter wrote: > On 30/05/22 2:48 pm, raf wrote: > > > If set > > > +empty (the default value) the search path is the one compiled into the > > > +Cyrus SASL library. > > > > I don't think that's entirely correct. On Debian, for > > example, the default value of cyrus_sasl_config_path is > > empty, and /etc/postfix/sasl is the directory that is > > used. They haven't changed the default value to be > > non-empty. > > It couldn't possibly be that they've compiled it into the cyrus sasl > library? > > > But it does look like it's not the postfix package that > > they changed. They changed the sasl2-bin package. > > The only executable binary that contains the string > > /etc/postfix/sasl is /usr/bin/saslfinger which is > > provided by the sasl2-bin package. > > Which suggests that it's been compiled into the cyrus sasl library. > > Peter No. Perhaps in the past, but no longer. I grepped for /etc/postfix/sasl in every file on a debian11 system and it didn't appear in libsasl2 or anywhere interesting. It did appear in things like saslfinger and apparmor rules and the postfix package file list and augeas-lenses (a config file parser). But nothing in any libsasl files or postfix files. cheers, raf
Re: Postfix+SASL chrooted - out of ideas (SASL_README tweak)
On Wed, Jun 01, 2022 at 01:35:56PM +1000, raf wrote: > > So what did they do? > > > > > $ postconf -d cyrus_sasl_config_path > > > cyrus_sasl_config_path = > > > $ postconf cyrus_sasl_config_path > > > cyrus_sasl_config_path = > > > $ dpkg-query -S /etc/postfix/sasl > > > postfix: /etc/postfix/sasl > > > > What would make anything look there? > > That's a very good question. I have no idea. I searched for > /etc/postfix/sasl in all files, not just the executable ones, and > found nothing that explains it. And there are no symlinks to it, > either. > > The Debian Postfix/SASL wiki page definitely indicates that that > directory is where Postfix's SASL config files go: > > https://wiki.debian.org/PostfixAndSASL > > I experimented to see if /etc/postfix/sasl is really used, and it > looks like it isn't. I think that my settings just happen to coincide > with libsasl2's defaults. Now it all begins to make sense, the Debian docs are wrong, and the search path is the default one (in no-way Postfix-specific) compiled into Cyrus SASL. And if some distro wants a Postfix-specific location, they'd need to mess around with symlinks or set "cyrus_sasl_config_path" by compiling in a different default value, or arranging for an override in main.cf at install time. So my suggested doc patch is pretty close, except perhaps that there are no distros actually doing this??? In which case the doc tweak can be somewhat different. -- Viktor.
Re: Postfix+SASL chrooted - out of ideas (SASL_README tweak)
On 30/05/22 2:48 pm, raf wrote: If set +empty (the default value) the search path is the one compiled into the +Cyrus SASL library. I don't think that's entirely correct. On Debian, for example, the default value of cyrus_sasl_config_path is empty, and /etc/postfix/sasl is the directory that is used. They haven't changed the default value to be non-empty. It couldn't possibly be that they've compiled it into the cyrus sasl library? But it does look like it's not the postfix package that they changed. They changed the sasl2-bin package. The only executable binary that contains the string /etc/postfix/sasl is /usr/bin/saslfinger which is provided by the sasl2-bin package. Which suggests that it's been compiled into the cyrus sasl library. Peter
Re: Postfix+SASL chrooted - out of ideas (SASL_README tweak)
On Mon, May 30, 2022 at 12:15:19AM -0400, Viktor Dukhovni wrote: > On Mon, May 30, 2022 at 12:48:46PM +1000, raf wrote: > > > I don't think that's entirely correct. On Debian, for > > example, the default value of cyrus_sasl_config_path is > > empty, and /etc/postfix/sasl is the directory that is > > used. > > Well, how exactly does that happen? I don't see any patches to Postfix > that would make it so at first blush. Changes to Cyrus SASL to always > look in /etc/postfix even for non-Postfix applications are exceedingly > unlikely, so something in Postfix would have to call sasl_set_path(3), > and that code uses the "cyrus_sasl_config_path" parameter. > > > They haven't changed the default value to be non-empty. > > So what did they do? > > > $ postconf -d cyrus_sasl_config_path > > cyrus_sasl_config_path = > > $ postconf cyrus_sasl_config_path > > cyrus_sasl_config_path = > > $ dpkg-query -S /etc/postfix/sasl > > postfix: /etc/postfix/sasl > > What would make anything look there? > > -- > Viktor. That's a very good question. I have no idea. I searched for /etc/postfix/sasl in all files, not just the executable ones, and found nothing that explains it. And there are no symlinks to it, either. The Debian Postfix/SASL wiki page definitely indicates that that directory is where Postfix's SASL config files go: https://wiki.debian.org/PostfixAndSASL But that doesn't explain how it works. The wiki page doesn't give instructions to set cyrus_sasl_config_path. Debian does provide its own default main.cf file, but cyrus_sasl_config_path isn't set in there. I've asked the postfix package maintainer for an explanation. I'll let you know if he answers. I experimented to see if /etc/postfix/sasl is really used, and it looks like it isn't. I think that my settings just happen to coincide with libsasl2's defaults. I'm explicitly setting smtpd_sasl_type and smtpd_sasl_path to their default values in main.cf (cyrus and smtpd). And Postfix's SASL readme and Debian's postfix package's contents lead me to think that /etc/postfix/sasl was important, and it all worked, but I just noticed that the 250-AUTH response includes NTLM which isn't in the mech_list directive of the /etc/postfix/conf/smtpd.conf file. So I renamed /etc/postfix/sasl/smtpd.conf to something else, and restarted postfix, and it still worked. So that directory is irrelevant. If I rename the file back, and symlink /etc/sasl2 to /etc/postfix/sasl, then the NTLM disappears from the 250-AUTH response and matches the config file. So, even though the Postfix SASL readme suggests the possibility, and the Debian postfix package and the Debian Postfix SASL wiki page indicate otherwise, there is nothing on Debian that makes libsasl2 look at /etc/postfix/sasl. Also, the default smtpd.conf file (when none is found) must be the equivalent of: pwcheck_method: auxprop auxprop_plugin: sasldb mech_list: DIGEST-MD5 CRAM-MD5 NTLM LOGIN PLAIN I'll modify that wiki page to add an instruction to set cyrus_sasl_config_path. It is an old page (2015). Presumably, it used to be correct then. And saslfinger definitely still thinks that /etc/postfix/sasl is relevant. When I have /etc/postfix/sasl/smtpd.conf, saslfinger -s reports its contents happily (because it looks in /etc/postfix/sasl even when nothing else does), but when I rename it, saslfinger -s claims that SASL can't work because there is no smtpd config. Perhaps is was relevant in the past but something changed since 2015. Actually, that wiki page is dreadful in several other ways. Thanks for the question. cheers, raf
Re: Postfix+SASL chrooted - out of ideas (SASL_README tweak)
On Mon, May 30, 2022 at 12:48:46PM +1000, raf wrote: > I don't think that's entirely correct. On Debian, for > example, the default value of cyrus_sasl_config_path is > empty, and /etc/postfix/sasl is the directory that is > used. Well, how exactly does that happen? I don't see any patches to Postfix that would make it so at first blush. Changes to Cyrus SASL to always look in /etc/postfix even for non-Postfix applications are exceedingly unlikely, so something in Postfix would have to call sasl_set_path(3), and that code uses the "cyrus_sasl_config_path" parameter. > They haven't changed the default value to be non-empty. So what did they do? > $ postconf -d cyrus_sasl_config_path > cyrus_sasl_config_path = > $ postconf cyrus_sasl_config_path > cyrus_sasl_config_path = > $ dpkg-query -S /etc/postfix/sasl > postfix: /etc/postfix/sasl What would make anything look there? -- Viktor.
Re: Postfix+SASL chrooted - out of ideas (SASL_README tweak)
On Sun, May 29, 2022 at 11:25:44AM -0400, Viktor Dukhovni
wrote:
> On Sat, May 28, 2022 at 10:32:56PM -0400, Viktor Dukhovni wrote:
>
> > > This might be irrelevant, but the SASL readme mentions
> > > that on some systems Postfix is modified to look for
> > > the Cyrus SASL config in /etc/postfix/sasl or
> > > /var/lib/sasl2. On Debian, it's in /etc/postfix/sasl.
> > > Perhaps "ln -s /etc/sasl2 /etc/postfix/sasl" might
> > > help.
> >
> > I don't expect this is a "modification in Postfix" as such, beyond
> > perhaps tweaking the built-in default of:
> >
> > http://www.postfix.org/postconf.5.html#cyrus_sasl_config_path
> >
> > which determines the search path for the "smtpd.conf" file. The default
> > is to use the path compiled into Cyrus SASL, which would of course not
> > be /etc/postfix/sasl (the Cyrus library is not Postfix-specific).
>
> If the configuration directory turns out to be the issue, or in any
> case..., perhaps the below patch to SASL_README might help someone else
> in the future.
>
> --
> Viktor.
>
> --- proto/SASL_README.html
> +++ proto/SASL_README.html
> @@ -267,10 +267,18 @@ in /usr/lib/sasl2/.
>Cyrus SASL version 2.1.22 and newer additionally search
> in /etc/sasl2/.
>
> - Some Postfix distributions are modified and look for the
> -Cyrus SASL configuration file in /etc/postfix/sasl/,
> -/var/lib/sasl2/ etc. See the distribution-specific
> -documentation to determine the expected location.
> + With Postfix 2.5 and later you can explicitly configure the
> +search path via the cyrus_sasl_config_path configuration
> +parameter. Specify zero or more colon-separated directories. If set
> +empty (the default value) the search path is the one compiled into the
> +Cyrus SASL library.
> +
> + Some Postfix distributions employ a non-empty default value
> +for cyrus_sasl_config_path to look for the Cyrus SASL
> +configuration file in /etc/postfix/sasl/,
> +/var/lib/sasl2/ etc. See the output of postconf
> +cyrus_sasl_config_path and/or the distribution-specific
> +documentation to determine the expected location.
>
>
>
I don't think that's entirely correct. On Debian, for
example, the default value of cyrus_sasl_config_path is
empty, and /etc/postfix/sasl is the directory that is
used. They haven't changed the default value to be
non-empty.
$ uname -a
Linux ook 5.10.0-14-amd64 #1 SMP Debian 5.10.113-1 (2022-04-29) x86_64
GNU/Linux
$ dpkg-query -l | grep postfix
ii postfix 3.5.6-1+b1 amd64High-performance mail transport agent
...
$ postconf -d cyrus_sasl_config_path
cyrus_sasl_config_path =
$ postconf cyrus_sasl_config_path
cyrus_sasl_config_path =
$ dpkg-query -S /etc/postfix/sasl
postfix: /etc/postfix/sasl
But perhaps other systems do use a non-empty default.
But it does look like it's not the postfix package that
they changed. They changed the sasl2-bin package.
The only executable binary that contains the string
/etc/postfix/sasl is /usr/bin/saslfinger which is
provided by the sasl2-bin package.
$ find /usr -type f -perm /111 -exec grep -l /etc/postfix/sasl '{}' ';'
/usr/bin/saslfinger
$ dpkg-query -S /usr/bin/saslfinger
sasl2-bin: /usr/bin/saslfinger
cheers,
raf
Re: Postfix+SASL chrooted - out of ideas
> On 29 May 2022, at 5:15 pm, Jim Garrison wrote: > > One possible suggestion for Postfix: Since it appears Postfix was > never able to even establish contact with Cyrus SASL, it might be nice > to detect that condition and provide a different error message than > just "authentication failed", to help with troubleshooting. I > also appreciate that that might actually require a change in libsasl > and not Postfix. As you surpmised, Postfix had no trouble using the Cyrus SASL library, the error indication is returned from the library, there's nothing Postfix can do to elicit a more precise error message. Cyrus SASL supports many mechanisms, and its use is justified if you need its advanced features. If you're already using Dovecot, and its SASL support meets your needs, that is typically the simpler choice. -- Viktor.
Re: Postfix+SASL chrooted - out of ideas
On 5/28/2022 7:07 PM, Viktor Dukhovni wrote: On Sat, May 28, 2022 at 05:11:22PM -0700, Jim Garrison wrote: Foreground saslauthd command, including debug output from successful testsaslauthd but no log entries corresponding to the immediately above extract from the Postfix log: $ sudo saslauthd -a pam -d -c -m /var/spool/postfix/var/run/saslauthd Why are you using the above "-m" option? The SASL library is going to look in "/var/run/saslauthd/mux", which corresponds to the default "-m /var/run/saslauthd". Unless the Postfix smtpd(8) process is chrooted, the default value is the only one that'll work. If you want to make saslauthd chroot-agnostic, make /var/run/saslauthd a symlink to /var/spool/postfix/var/run/saslauthd. But simpler to just not bother with chroot. Well, since I was making no progress with cyrus SASL I decided to switch to Dovecot following the Postfix SASL howto, and it worked first time. Viktor et al, thank you for your assistance. I've spent way too much time on this, and should have just switched to dovecot auth at the start. I foolishly assumed since I had it working on the ancient system it would be at least as easy on a modern system. The documentation tweak I'd recommend is to more strongly steer users towards using dovecot auth instead of cyrus SASL. This is based on my own experience plus reading the many posts from others, in various forums, who were also having trouble with Cyrus SASL. While I hate using cookbook solutions (where I cannot abstract the intuitive understanding of what's going on under the covers), in this case it'll have to do. I just don't have the time or inclination to become an expert in the architecture, design and implementation of either Cyrus SASL or Dovecot. (sigh! so much to learn, so little time) One possible suggestion for Postfix: Since it appears Postfix was never able to even establish contact with Cyrus SASL, it might be nice to detect that condition and provide a different error message than just "authentication failed", to help with troubleshooting. I also appreciate that that might actually require a change in libsasl and not Postfix. Thanks again -- Jim Garrison j...@acm.org
Re: Postfix+SASL chrooted - out of ideas (SASL_README tweak)
On Sat, May 28, 2022 at 10:32:56PM -0400, Viktor Dukhovni wrote: > > This might be irrelevant, but the SASL readme mentions > > that on some systems Postfix is modified to look for > > the Cyrus SASL config in /etc/postfix/sasl or > > /var/lib/sasl2. On Debian, it's in /etc/postfix/sasl. > > Perhaps "ln -s /etc/sasl2 /etc/postfix/sasl" might > > help. > > I don't expect this is a "modification in Postfix" as such, beyond > perhaps tweaking the built-in default of: > > http://www.postfix.org/postconf.5.html#cyrus_sasl_config_path > > which determines the search path for the "smtpd.conf" file. The default > is to use the path compiled into Cyrus SASL, which would of course not > be /etc/postfix/sasl (the Cyrus library is not Postfix-specific). If the configuration directory turns out to be the issue, or in any case..., perhaps the below patch to SASL_README might help someone else in the future. -- Viktor. --- proto/SASL_README.html +++ proto/SASL_README.html @@ -267,10 +267,18 @@ in /usr/lib/sasl2/. Cyrus SASL version 2.1.22 and newer additionally search in /etc/sasl2/. - Some Postfix distributions are modified and look for the -Cyrus SASL configuration file in /etc/postfix/sasl/, -/var/lib/sasl2/ etc. See the distribution-specific -documentation to determine the expected location. + With Postfix 2.5 and later you can explicitly configure the +search path via the cyrus_sasl_config_path configuration +parameter. Specify zero or more colon-separated directories. If set +empty (the default value) the search path is the one compiled into the +Cyrus SASL library. + + Some Postfix distributions employ a non-empty default value +for cyrus_sasl_config_path to look for the Cyrus SASL +configuration file in /etc/postfix/sasl/, +/var/lib/sasl2/ etc. See the output of postconf +cyrus_sasl_config_path and/or the distribution-specific +documentation to determine the expected location.
Re: Postfix+SASL chrooted - out of ideas
On Sun, May 29, 2022 at 12:12:29PM +1000, raf wrote: > On Sat, May 28, 2022 at 05:11:22PM -0700, Jim Garrison wrote: > > > For completeness here's everything I can think of that could be > > related: > > > > $ ls -ld /etc/sasl2 > > drwxr-xr-x 2 root root 4096 May 19 00:58 /etc/sasl2 > > > > $ ls -l /etc/sasl2/ > > -rw-r--r-- 1 root root 62 May 28 18:18 smtpd.conf > > > > $ cat /etc/sasl2/smtpd.conf > > pwcheck_method: saslauthd > > log_level: 7 > > mech_list: PLAIN LOGIN > > This might be irrelevant, but the SASL readme mentions > that on some systems Postfix is modified to look for > the Cyrus SASL config in /etc/postfix/sasl or > /var/lib/sasl2. On Debian, it's in /etc/postfix/sasl. > Perhaps "ln -s /etc/sasl2 /etc/postfix/sasl" might > help. I don't expect this is a "modification in Postfix" as such, beyond perhaps tweaking the built-in default of: http://www.postfix.org/postconf.5.html#cyrus_sasl_config_path which determines the search path for the "smtpd.conf" file. The default is to use the path compiled into Cyrus SASL, which would of course not be /etc/postfix/sasl (the Cyrus library is not Postfix-specific). The OP could explicitly set: cyrus_sasl_config_path = or even (expected to be equivalent): cyrus_sasl_config_path = /etc/sasl2 The OP could check the default value: postconf -d cyrus_sasl_config_path -- Viktor.
Re: Postfix+SASL chrooted - out of ideas
On Sat, May 28, 2022 at 05:11:22PM -0700, Jim Garrison wrote: > For completeness here's everything I can think of that could be > related: > > $ ls -ld /etc/sasl2 > drwxr-xr-x 2 root root 4096 May 19 00:58 /etc/sasl2 > > $ ls -l /etc/sasl2/ > -rw-r--r-- 1 root root 62 May 28 18:18 smtpd.conf > > $ cat /etc/sasl2/smtpd.conf > pwcheck_method: saslauthd > log_level: 7 > mech_list: PLAIN LOGIN This might be irrelevant, but the SASL readme mentions that on some systems Postfix is modified to look for the Cyrus SASL config in /etc/postfix/sasl or /var/lib/sasl2. On Debian, it's in /etc/postfix/sasl. Perhaps "ln -s /etc/sasl2 /etc/postfix/sasl" might help. cheers, raf
Re: Postfix+SASL chrooted - out of ideas
On Sat, May 28, 2022 at 05:11:22PM -0700, Jim Garrison wrote: > Foreground saslauthd command, including debug output from > successful testsaslauthd but no log entries corresponding to the > immediately above extract from the Postfix log: > > $ sudo saslauthd -a pam -d -c -m /var/spool/postfix/var/run/saslauthd Why are you using the above "-m" option? The SASL library is going to look in "/var/run/saslauthd/mux", which corresponds to the default "-m /var/run/saslauthd". Unless the Postfix smtpd(8) process is chrooted, the default value is the only one that'll work. If you want to make saslauthd chroot-agnostic, make /var/run/saslauthd a symlink to /var/spool/postfix/var/run/saslauthd. But simpler to just not bother with chroot. -- Viktor.
Re: Postfix+SASL chrooted - out of ideas
On 29/05/22 12:11 pm, Jim Garrison wrote: 1) The command I got from an internet post to generate the base64 encoded user/password was incorrect, or intended for a different version of the echo command. In $ echo -ne '\000myu...@mydomain.com\000[password]' | base64 bash echo expects numeric escapes to be \0nnn. It correctly parsed the first \000 but my password happens to start with a digit, so it didn't generate the nul there. I needed \ instead. Random sites on the internet tend to give bad advice to use the unreliable echo command for this. This is better (and is in the postfix SASL_README doc): printf '\0%s\0%s' 'username' 'password' | openssl base64 Peter
Re: Postfix+SASL chrooted - out of ideas
On 5/28/2022 2:21 PM, Viktor Dukhovni wrote: [ Please respect the "Reply-To" header] Oops, sorry, will do. I'm making some progress. I turned on debug tracing in postfix and saslauthd and made some interesting discoveries: 1) The command I got from an internet post to generate the base64 encoded user/password was incorrect, or intended for a different version of the echo command. In $ echo -ne '\000myu...@mydomain.com\000[password]' | base64 bash echo expects numeric escapes to be \0nnn. It correctly parsed the first \000 but my password happens to start with a digit, so it didn't generate the nul there. I needed \ instead. THAT EXPLAINS THE PROTOCOL ERROR 2) After fixing that issue it still fails with a slightly different error: 535 5.7.8 Error: authentication failed: authentication failure The crucial bit of information is that, with saslauthd running in the foreground, with debug enabled, NOTHING GETS LOGGED, even though I see log entries when running testsaslauthd. I conclude therefore that the Postfix-to-saslauthd communication isn't working, which narrows down the problem. For completeness here's everything I can think of that could be related: $ ls -ld /etc/sasl2 drwxr-xr-x 2 root root 4096 May 19 00:58 /etc/sasl2 $ ls -l /etc/sasl2/ -rw-r--r-- 1 root root 62 May 28 18:18 smtpd.conf $ cat /etc/sasl2/smtpd.conf pwcheck_method: saslauthd log_level: 7 mech_list: PLAIN LOGIN Extract from Postfix debug log (with correctly formatted base64 string) : < localhost[127.0.0.1]: AUTH PLAIN [redacted] : xsasl_cyrus_server_first: sasl_method PLAIN, init_response [redacted] : xsasl_cyrus_server_first: decoded initial response : warning: SASL authentication failure: Password verification failed : warning: localhost[127.0.0.1]: SASL PLAIN authentication failed: authentication failure : > localhost[127.0.0.1]: 535 5.7.8 Error: authentication failed: authentication failure Foreground saslauthd command, including debug output from successful testsaslauthd but no log entries corresponding to the immediately above extract from the Postfix log: $ sudo saslauthd -a pam -d -c -m /var/spool/postfix/var/run/saslauthd saslauthd[27086] :num_procs : 5 saslauthd[27086] :mech_option: NULL saslauthd[27086] :run_path : /var/spool/postfix/var/run/saslauthd saslauthd[27086] :auth_mech : pam saslauthd[27086] :mmaped shared memory segment on file: /var/spool/postfix/var/run/saslauthd/cache.mmap saslauthd[27086] :bucket size: 96 bytes saslauthd[27086] :stats size : 36 bytes saslauthd[27086] :timeout: 28800 seconds saslauthd[27086] :cache table: 985828 total bytes saslauthd[27086] :cache table: 1711 slots saslauthd[27086] :cache table: 10266 buckets saslauthd[27086] :flock file opened at /var/spool/postfix/var/run/saslauthd/cache.flock saslauthd[27086] :using accept lock file: /var/spool/postfix/var/run/saslauthd/mux.accept saslauthd[27086] :master pid is: 0 saslauthd[27086] :listening on socket: /var/spool/postfix/var/run/saslauthd/mux saslauthd[27086] :using process model saslauthd[27086] :forked child: 27087 saslauthd[27086] :forked child: 27088 saslauthd[27086] :forked child: 27089 saslauthd[27086] :forked child: 27090 saslauthd[27086] :acquired accept lock saslauthd[27086] :released accept lock saslauthd[27089] :acquired accept lock saslauthd[27089] :attempting a read lock on slot: 543 saslauthd[27089] :[login=jhg] [service=smtpd] [realm=]: not found, update pending saslauthd[27089] :attempting to release lock on slot: 543 saslauthd[27089] :attempting a write lock on slot: 543 saslauthd[27089] :lookup committed saslauthd[27089] :attempting to release lock on slot: 543 saslauthd[27089] :auth success: [user=jhg] [service=smtpd] [realm=] [mech=pam] saslauthd[27089] :response: OK $ sudo postconf |egrep 'smtpd_sasl|tls_auth' smtpd_sasl_auth_enable = no smtpd_sasl_authenticated_header = yes smtpd_sasl_exceptions_networks = smtpd_sasl_local_domain = smtpd_sasl_path = smtpd smtpd_sasl_response_limit = 12288 smtpd_sasl_security_options = noanonymous smtpd_sasl_service = smtp smtpd_sasl_tls_security_options = $smtpd_sasl_security_options smtpd_sasl_type = cyrus smtpd_tls_auth_only = yes Directory permissions: $ ls -ld /var/spool/postfix drwxr-xr-x 21 root root 4096 May 27 21:42 /var/spool/postfix $ ls -ld /var/spool/postfix/var drwxr-xr-x 3 root root 4096 May 27 21:42 /var/spool/postfix/var $ ls -ld /var/spool/postfix/var/run drwxr-xr-x 3 root root 4096 May 27 21:42 /var/spool/postfix/var/run $ ls -ld /var/spool/postfix/var/run/saslauthd/ drwxr-x--- 2 root sasl 4096 May 28 23:30 /var/spool/postfix/var/run/saslauthd/ $ sudo ls -l /var/spool/postfix/var/run/saslauthd/ total 964 -rw--- 1 root root 0 May 28 23:30 cache.flock -rw--- 1 root root 986112 May 28 23:51 cache.mmap srwxrwxrwx 1 root root 0 May 28 23:30 mux -rw--- 1 root root 0 May 28 23:30 mux.accept -rw--- 1 root root 0 May 28 23:30 saslauthd.pid.lock $
Re: Postfix+SASL chrooted - out of ideas
On Fri, May 27, 2022 at 06:22:01PM -0700, Jim Garrison wrote: > I'm migrating from an ancient Postfix 2.6.6 with SASL 2.1.23 on Centos > 6 to 3.5.6 with SASL 2.1.27 on Debian 11. I've got everything working > EXCEPT SASL authentication, and the amount of conflicting information > on Postfix+SASL on the web is rather amazing :-). I've recently done a similar thing, replacing an 11 year old mail server for someone, and encountered a similar-sounding problem. The passwords are in /etc/sasldb2, but that file isn't accessible by chrooted postfix processes. I moved it to /var/spool/postfix/etc/sasldb2 and created a symlink to it at /etc/sasldb2. That might be the cause, but bear in mind Viktor's comments about the lack of security in having unhashed passwords on disk. > -- > Jim Garrison > j...@acm.org cheers, raf
Re: Postfix+SASL chrooted - out of ideas
[ Please respect the "Reply-To" header] On Sat, May 28, 2022 at 12:47:24PM -0700, Jim Garrison wrote: > On 5/27/2022 8:31 PM, Viktor Dukhovni wrote: > > Why not just read the SASL_README that comes with Postfix, e.g. at: > > > > https://www.postfix.org/SASL_README.html > > OK, I did just that, with exactly the same results. Clearly I'm missing > something simple but critical, and the lack of good documentation on > the underlying pieces (pam, saslauthd, etc) is frustrating :-( When using Cyrus SASL for authentication of submission users (if you're not using "dovecot", which is generally easier to set up) indeed "saslauthd -a pam" is the saner option. > Here's what I've got: > > smtpd_sasl_type = cyrus > smtpd_sasl_auth_enable = yes May as well set it to "no" in main.cf, and only enable in master.cf on the submission ports (as you appear to have done). > smtpd_sasl_authenticated_header = yes > smtpd_sasl_path = smtpd > smtpd_sasl_response_limit = 12288 > smtpd_sasl_security_options = noanonymous > smtpd_sasl_service = smtp > smtpd_sasl_tls_security_options = $smtpd_sasl_security_options Don't forget: http://www.postfix.org/postconf.5.html#smtpd_tls_auth_only > I assume smtpd_sasl_service is passed through saslauthd when using pam > and provides what pam calls "service name". I tried a search for > "list of pam service names" and nothing I found mentioned "smtp" or > "smtpd". See: http://www.postfix.org/postconf.5.html#smtpd_sasl_service the default value is "smtp" and should rarely if ever be changed, this is used in e.g. GSSAPI to infer the correct service name to construct the server principal name for keytab lookups, ... It is the first argument to sasl_server_new(3): ... int sasl_server_new(const char *service, const char *serverFQDN, const char *user_realm, const char *iplocalport, const char *ipremoteport, const sasl_callback_t *callbacks, unsigned flags, sasl_conn_t ** pconn); DESCRIPTION sasl_server_new() creates a new SASL context. This context will be used for all SASL calls for one connection. It handles both authentication and integrity/encryption layers after authentication. service is the registered name of the service (usually the protocol name) using SASL (e.g. "imap"). ... This is then passed to "saslauthd", which in turn passes it to pam_start(3): int pam_start(const char *service, const char *user, const struct pam_conv *pam_conv, pam_handle_t **pamh); DESCRIPTION The pam_start function creates and initializes a PAM context. The service argument specifies the name of the policy to apply, and is stored in the PAM_SERVICE item in the created context. So indeed the pam.d configuration file name needs to match the configured service name (in this case "smtp"). > $ cat /etc/sasl2/smtpd.conf > pwcheck_method: saslauthd > mech_list: PLAIN LOGIN > log_level: 7 This looks reasonable, ... > (log_level doesn't seem to affect any logging that I can see) I'm not familiar with the details of "log_level", perhaps it is not expected to have any effect. > $ cat /etc/default/saslauthd > START=yes > DESC="SASL Authentication Daemon" > NAME="saslauthd" > MECHANISMS="pam" > MECH_OPTIONS="" > THREADS=5 > OPTIONS="-c -m /var/spool/postfix/var/run/saslauthd" Is "saslauthd" actually running? Do the process arguments include "-a pam"? Is the "mux" socket in place? ... > Testing saslauthd (after deleting /etc/sasldb2 and restarting > the saslauthd service) > > $ sudo testsaslauthd -u myuser -p [password] > 0: OK "Success." This suggests yes... > $ cat /etc/pam.d/smtp > authrequiredpam_unix.so no_warn > (I'll do the group thing later) Looks fine. > And finally, I disabled chroot in master.cf: > > smtp inet n - n - - smtpd > submission inet n - n - - smtpd >-o syslog_name=postfix/submission >-o smtpd_tls_security_level=encrypt >-o smtpd_sasl_auth_enable=yes See above re defaulting "auth_enable" to "no". > The error is still consistently > > 535 5.7.8 Error: authentication failed: bad protocol / cancel This particular error is unexpected, it generally indicates that the SASL server believes the "AUTH" command from the client to be malformed or otherwise invalid. To debug that, you may want to create a temporary test user with a password you're willing to leak to this list (after disabling the account). You can then report the SMTP dialogue between client and server by running the submission service with a "-v" option. Do make sure that you've installed all the requisite Cyrus libraries and mechanism plugins, that file permissions are correct, that you've restarted Postfix (just in case master(8)
Re: Postfix+SASL chrooted - out of ideas
On Fri, May 27, 2022 at 06:22:01PM -0700, Jim Garrison wrote: > I'm migrating from an ancient Postfix 2.6.6 with SASL 2.1.23 on Centos > 6 to 3.5.6 with SASL 2.1.27 on Debian 11. I've got everything working > EXCEPT SASL authentication, and the amount of conflicting information > on Postfix+SASL on the web is rather amazing :-). Why not just read the SASL_README that comes with Postfix, e.g. at: https://www.postfix.org/SASL_README.html and skip the various false leads on the Internet? > $sudo sasldblistusers2 > myu...@mydomain.com: userPassword Why do you want to use "sasldb" with passwords stored in cleartext? Sure support various mechanisms that don't transmit the password from the user to the server, but the bigger risk is *storing* the password on the server. You're generally much better off with hashed passwords and PLAIN inside TLS. > $cat /etc/sasl2/smtpd.conf > pwcheck_method: auxprop > log_level: 4 > mech_list: PLAIN When using "auxprop", I'd expect to also see a setting for "auxprop_plugin", and perhaps additional related parameters. > smtpd_sasl_auth_enable = yes > smtpd_sasl_authenticated_header = no > smtpd_sasl_exceptions_networks = > smtpd_sasl_local_domain = > smtpd_sasl_path = smtpd > smtpd_sasl_response_limit = 12288 > smtpd_sasl_security_options = noanonymous > smtpd_sasl_service = smtpd > smtpd_sasl_tls_security_options = $smtpd_sasl_security_options > smtpd_sasl_type = cyrus Ideally, you also have "smtpd_tls_auth_only = yes", > Since the Debian default is to run Postfix chroot, I applied the fix > suggested to make the SASL socket available to Postfix (OPTIONS below) Instead get smtpd(8) + SASL working *without* chroot first, with "auxprop" and "sasldb" smtpd(8) would need to be able to read the SASL database, which would be challenging after chroot, and perhaps also when running as the "postfix" user, rather than "root". You'd be better off with "saslauthd" + PAM, and ideally limit which users are eligible to authenticated that way, in case some accounts that should not authenticate have weak passwords. I use the "dovecot" SASL driver, with: # cat /etc/pam.d/dovecot authrequiredpam_group.sono_warn group=pamimap authrequiredpam_unix.so no_warn Users have to be in group "pamimap" in order use the "pam" backend. > $ cat /etc/default/saslauthd > START=yes > DESC="SASL Authentication Daemon" > NAME="saslauthd" > MECHANISMS="sasldb" > MECH_OPTIONS="" > THREADS=5 > OPTIONS="-c -m /var/spool/postfix/var/run/saslauthd" You're not using "saslauthd", that's an alternative "pwcheck_method" to "auxprop" (that you should consider instead, via "saslauthd -a pam", or use the dovecot driver). -- Viktor.
Postfix+SASL chrooted - out of ideas
I'm migrating from an ancient Postfix 2.6.6 with SASL 2.1.23 on Centos 6 to 3.5.6 with SASL 2.1.27 on Debian 11. I've got everything working EXCEPT SASL authentication, and the amount of conflicting information on Postfix+SASL on the web is rather amazing :-). I tried reading the Cyrus SASL manual, but it seems to be incomplete, with lots of headings with no text. I have authentication working just fine on my old system (for years), but I'm stumped on the new system after about 10 hours of experimentation. Here's the current setup (sensitive info redacted): $sudo sasldblistusers2 myu...@mydomain.com: userPassword $ sudo testsaslauthd -r mydomain.com -u myuser -p [password] 0: OK "Success." So I know SASL itself is working, but in case it's relevant: $ sudo db_dump -p /etc/sasldb2 VERSION=3 format=print type=hash h_nelem=2 db_pagesize=4096 HEADER=END myuser\00mydomain.com\00userPassword [password] DATA=END $cat /etc/sasl2/smtpd.conf pwcheck_method: auxprop log_level: 4 mech_list: PLAIN $ sudo postconf -a cyrus dovecot $ sudo postconf |egrep '^smtpd_(sasl|relay)' smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated reject_unauth_destination smtpd_sasl_auth_enable = yes smtpd_sasl_authenticated_header = no smtpd_sasl_exceptions_networks = smtpd_sasl_local_domain = smtpd_sasl_path = smtpd smtpd_sasl_response_limit = 12288 smtpd_sasl_security_options = noanonymous smtpd_sasl_service = smtpd smtpd_sasl_tls_security_options = $smtpd_sasl_security_options smtpd_sasl_type = cyrus Since the Debian default is to run Postfix chroot, I applied the fix suggested to make the SASL socket available to Postfix (OPTIONS below) $ cat /etc/default/saslauthd START=yes DESC="SASL Authentication Daemon" NAME="saslauthd" MECHANISMS="sasldb" MECH_OPTIONS="" THREADS=5 OPTIONS="-c -m /var/spool/postfix/var/run/saslauthd" $ groups postfix postfix : postfix sasl $ ls -ld /var/spool/postfix drwxr-xr-x 21 root root 4096 May 27 21:42 /var/spool/postfix $ ls -ld /var/spool/postfix/var drwxr-xr-x 3 root root 4096 May 27 21:42 /var/spool/postfix/var $ ls -ld /var/spool/postfix/var/run drwxr-xr-x 3 root root 4096 May 27 21:42 /var/spool/postfix/var/run $ ls -ld /var/spool/postfix/var/run/saslauthd/ drwx--x--- 2 root sasl 4096 May 28 00:41 /var/spool/postfix/var/run/saslauthd/ $ sudo ls -l /var/spool/postfix/var/run/saslauthd/mux srwxrwxrwx 1 root root 0 May 28 00:41 /var/spool/postfix/var/run/saslauthd/mux Thunderbird client configuration (same as working config that connects to the old system, except for the hostname). Host: hostname of the new server Port: 587 User: myu...@mydomain.com Auth: Normal Password Sec: STARTTLS The consistent error is (/var/log/mail.log) May 28 00:50:34 smtp2 postfix/submission/smtpd[19147]: connect from [redacted] May 28 00:50:35 smtp2 postfix/submission/smtpd[19147]: warning: SASL authentication failure: Password verification failed May 28 00:50:35 smtp2 postfix/submission/smtpd[19147]: warning: [redacted]: SASL PLAIN authentication failed: authentication failure There is nothing logged in auth.log, and journalctl does not show anything for saslauthd except daemon start and stop messages. So I'm out of ideas. What can I do to resolve the problem or troubleshoot further? I also tried manually connecting, here's the results of that session: $ echo -ne '\000myu...@mydomain.com\000[password]' | openssl base64 [redacted base64] $ openssl s_client -connect localhost:587 -starttls smtp CONNECTED(0003) [certificate data] --- SSL handshake has read 4810 bytes and written 396 bytes Verification: OK --- New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384 Server public key is 2048 bit Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated Early data was not sent Verify return code: 0 (ok) --- 250 CHUNKING --- [session ticket] --- read R BLOCK EHLO test.com 250-[redacted] 250-PIPELINING 250-SIZE 1024 250-VRFY 250-ETRN 250-AUTH DIGEST-MD5 CRAM-MD5 NTLM PLAIN LOGIN 250-ENHANCEDSTATUSCODES 250-8BITMIME 250-DSN 250-SMTPUTF8 250 CHUNKING AUTH PLAIN [redacted base64] 535 5.7.8 Error: authentication failed: bad protocol / cancel QUIT DONE -- Jim Garrison j...@acm.org
