2.3.8->2.5.1 upgrade breaks dovecot SASL auth

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

2.3.8->2.5.1 upgrade breaks dovecot SASL auth

martin f krafft-2
Hi list,

I upgraded my postfix 2.3.8 server to 2.5.1 today to get
smtpd_tls_fingerprint_digest and be able to use SHA-1 fingerprints.
Unfortunately, that broke SASL, so it seems.

I am using Dovecot according to the SASL_README. The auth socket
exists and has the appropriate permissions:

  srw-rw---- 1 postfix postfix 0 2008-06-15 11:29 /var/spool/postfix/private/auth

I have postfix configured like this:

  smtpd_sasl_auth_enable = yes
  smtpd_tls_auth_only = yes
  smtpd_sasl_local_domain = smtprelay.madduck.net
  smtpd_sasl_authenticated_header = yes
  smtpd_sasl_type = dovecot
  smtpd_sasl_path = private/auth
  smtpd_sasl_tls_security_options = noanonymous
  smtpd_sasl_security_options = mutual_auth $smtpd_sasl_tls_security_options
  broken_sasl_auth_clients = no

This works fine with 2.3.8.

As soon as I upgrade to 2.5.1, smtpd won't accept any new
connections, rejecting them even before sending the SMTP banner. The
logs state:

  postfix/smtpd[14066]: fatal: no SASL authentication mechanisms
  postfix/master[14051]: warning: process /usr/lib/postfix/smtpd pid 14066 exit status 1
  postfix/master[14051]: warning: /usr/lib/postfix/smtpd: bad command startup -- throttling

I tried enabling debug_peer_*, but that yields no additional
information. I also enabled dovecot's auth_debug, but that shows
nothing for connections to the auth socket, only for logins to e.g.
imaps, which work fine.

I tried changing the auth socket path and then postfix would
complain:

  postfix/smtpd[12570]: warning: SASL: Connect to private/authxx failed: No such file or directory

so I changed it back and the warning went away, but smtpd still
complains about having no SASL mechs available.

I don't have saslauthd enabled since it's unnecessary for dovecot
auth. I don't even have libsasl2-modules installed.

If I downgrade postfix 2.5.1 to 2.3.8, everything returns to normal
again and SASL works.

I tried to scan the postfix changelog but could not find anything
pertinent.

Looking at the Debian changelog, I see

  - sasl: enforce mechanism output filter on client command input.

which was cherry-picked from 2.5.2. Could this be the reason?

Or is there something else between 2.3.8 and 2.5.1 which
I overlooked?

--
martin | http://madduck.net/ | http://two.sentenc.es/
 
"a scientist once wrote that all truth passes through three stages:
 first it is ridiculed, then violently opposed and eventually,
 accepted as self-evident."
                                                       -- schopenhauer
 
spamtraps: [hidden email]

digital_signature_gpg.asc (204 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: 2.3.8->2.5.1 upgrade breaks dovecot SASL auth

Wietse Venema
martin f krafft:
>   postfix/smtpd[14066]: fatal: no SASL authentication mechanisms

The dovecot authentication server does not provide any authentication
mechanisms that are allowed by Postfix main.cf settings:

   smtpd_sasl_tls_security_options = noanonymous
   smtpd_sasl_security_options = mutual_auth $smtpd_sasl_tls_security_options

This "worked" because old Postfix versions ignore *_security_options
settings with Dovecot SASL. The old code did not have _security_options
support, but instead, relied on the settings in the Dovecot
configuration file.

What "mutual_auth" security mechanisms did you have in mind when
configuring this in main.cf? Are these mechanisms supported by the
Dovecot authentication server? By the SMTP client?

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: 2.3.8->2.5.1 upgrade breaks dovecot SASL auth

martin f krafft-2
also sprach Wietse Venema <[hidden email]> [2008.06.15.1519 +0200]:

> The dovecot authentication server does not provide any
> authentication mechanisms that are allowed by Postfix main.cf
> settings:
>
>    smtpd_sasl_tls_security_options = noanonymous
>    smtpd_sasl_security_options = mutual_auth $smtpd_sasl_tls_security_options
>
> This "worked" because old Postfix versions ignore
> *_security_options settings with Dovecot SASL. The old code did
> not have _security_options support, but instead, relied on the
> settings in the Dovecot configuration file.
Since I am using TLS, only noanonymous will be in effect (and not
noplaintext, thus plaintext should be allowed); Yet, the two
mechanisms, LOGIN and PLAIN, which dovecot offers, don't work. To my
understanding, neither of them allows anonymous logins.

> What "mutual_auth" security mechanisms did you have in mind when
> configuring this in main.cf? Are these mechanisms supported by the
> Dovecot authentication server? By the SMTP client?

That's a left-over from when I played around with the setting. Since
I require TLS for AUTH, smtpd_sasl_security_options never comes into
play, right?

I just tried this and it seems my assumption is wrong. If I remove
any setting of smtpd_sasl_security_options but leave
smtpd_sasl_tls_security_options=noanonymous, then it suddenly works.

So it seems that smtpd_tls_auth_only does not make
smtpd_sasl_security_options obsolete at all, which seems wrong to
me...

--
martin | http://madduck.net/ | http://two.sentenc.es/
 
if you see an onion ring -- answer it!
 
spamtraps: [hidden email]

digital_signature_gpg.asc (204 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: 2.3.8->2.5.1 upgrade breaks dovecot SASL auth

Wietse Venema
martin f krafft:

> also sprach Wietse Venema <[hidden email]> [2008.06.15.1519 +0200]:
> > The dovecot authentication server does not provide any
> > authentication mechanisms that are allowed by Postfix main.cf
> > settings:
> >
> >    smtpd_sasl_tls_security_options = noanonymous
> >    smtpd_sasl_security_options = mutual_auth $smtpd_sasl_tls_security_options
> >
> > This "worked" because old Postfix versions ignore
> > *_security_options settings with Dovecot SASL. The old code did
> > not have _security_options support, but instead, relied on the
> > settings in the Dovecot configuration file.
...
> I just tried this and it seems my assumption is wrong. If I remove
> any setting of smtpd_sasl_security_options but leave
> smtpd_sasl_tls_security_options=noanonymous, then it suddenly works.
>
> So it seems that smtpd_tls_auth_only does not make
> smtpd_sasl_security_options obsolete at all, which seems wrong to
> me...

The SMTP session starts in PLAINTEXT, and that is when the
smtpd_sasl_tls_security_options are being used.

Changing this is not simply a matter of delaying the per-session
SASL initialization until the client issues the AUTH command: it
must not segfault with clients that send zero AUTH commands, and
it must not leak memory with clients that send multiple auth
commands. I am rather busy working on other things now, and as this
is not urgent, this will have to wait.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: 2.3.8->2.5.1 upgrade breaks dovecot SASL auth

martin f krafft-2
also sprach Wietse Venema <[hidden email]> [2008.06.15.2157 +0200]:
> The SMTP session starts in PLAINTEXT, and that is when the
> smtpd_sasl_tls_security_options are being used.

I assumed you meant s/_tls//: smtpd_sasl_security_options (without
the tls)

> Changing this is not simply a matter of delaying the per-session
> SASL initialization until the client issues the AUTH command: it
> must not segfault with clients that send zero AUTH commands, and
> it must not leak memory with clients that send multiple auth
> commands. I am rather busy working on other things now, and as this
> is not urgent, this will have to wait.

Ok. Should I file a bug report for posterity anywhere? Or just ping
you again in x months? Please define x...

--
martin | http://madduck.net/ | http://two.sentenc.es/
 
Most Intelligent Customers Realise Our Software Only Fools Them.
 
spamtraps: [hidden email]

digital_signature_gpg.asc (204 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: 2.3.8->2.5.1 upgrade breaks dovecot SASL auth

Wietse Venema
martin f krafft:

> also sprach Wietse Venema <[hidden email]> [2008.06.15.2157 +0200]:
> > The SMTP session starts in PLAINTEXT, and that is when the
> > smtpd_sasl_tls_security_options are being used.
>
> I assumed you meant s/_tls//: smtpd_sasl_security_options (without
> the tls)
>
> > Changing this is not simply a matter of delaying the per-session
> > SASL initialization until the client issues the AUTH command: it
> > must not segfault with clients that send zero AUTH commands, and
> > it must not leak memory with clients that send multiple auth
> > commands. I am rather busy working on other things now, and as this
> > is not urgent, this will have to wait.
>
> Ok. Should I file a bug report for posterity anywhere? Or just ping
> you again in x months? Please define x...

It is on the TODO list, which contains items from 10 years ago.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: 2.3.8->2.5.1 upgrade breaks dovecot SASL auth

Victor Duchovni
In reply to this post by martin f krafft-2
On Sun, Jun 15, 2008 at 10:13:48PM +0200, martin f krafft wrote:

> Ok. Should I file a bug report for posterity anywhere? Or just ping
> you again in x months? Please define x...


  smtpd_sasl_auth_enable = yes
  smtpd_tls_auth_only = yes
  smtpd_sasl_tls_security_options = noanonymous
  smtpd_sasl_security_options = mutual_auth $smtpd_sasl_tls_security_options

You are asking for SASL only with TLS.

  postfix/smtpd[14066]: fatal: no SASL authentication mechanisms

but smtpd makes a SASL connection early before TLS is active. Try the
patch below (based on 2.6, but should work with 2.5):

Index: src/smtpd/smtpd.c
--- src/smtpd/smtpd.c 9 May 2008 00:27:26 -0000 1.1.1.4.2.1
+++ src/smtpd/smtpd.c 15 Jun 2008 21:32:05 -0000
@@ -3919,9 +3919,12 @@
      */
 #ifdef USE_SASL_AUTH
     if (var_smtpd_sasl_enable
- && strcmp(var_smtpd_sasl_tls_opts, var_smtpd_sasl_opts) != 0) {
- smtpd_sasl_auth_reset(state);
- smtpd_sasl_disconnect(state);
+ && (state->tls_auth_only
+    || strcmp(var_smtpd_sasl_tls_opts, var_smtpd_sasl_opts) != 0)) {
+ if (state->tls_auth_only == 0) {
+    smtpd_sasl_auth_reset(state);
+    smtpd_sasl_disconnect(state);
+ }
  smtpd_sasl_connect(state, VAR_SMTPD_SASL_TLS_OPTS,
    var_smtpd_sasl_tls_opts);
     }
@@ -4431,28 +4434,6 @@
     msg_info("connect from %s", state.namaddr);
 
     /*
-     * With TLS wrapper mode, we run on a dedicated port and turn on TLS
-     * before actually speaking the SMTP protocol. This implies TLS enforce
-     * mode.
-     *
-     * With non-wrapper mode, TLS enforce mode implies that we don't advertise
-     * AUTH before the client issues STARTTLS.
-     */
-#ifdef USE_TLS
-    if (!SMTPD_STAND_ALONE((&state))) {
- if (var_smtpd_tls_wrappermode) {
-    state.tls_use_tls = 1;
-    state.tls_enforce_tls = 1;
- } else {
-    state.tls_use_tls = var_smtpd_use_tls | var_smtpd_enforce_tls;
-    state.tls_enforce_tls = var_smtpd_enforce_tls;
- }
- if (var_smtpd_tls_auth_only || state.tls_enforce_tls)
-    state.tls_auth_only = 1;
-    }
-#endif
-
-    /*
      * XCLIENT must not override its own access control.
      */
     xclient_allowed =
Index: src/smtpd/smtpd_state.c
--- src/smtpd/smtpd_state.c 16 Jan 2008 04:42:25 -0000 1.1.1.1
+++ src/smtpd/smtpd_state.c 15 Jun 2008 21:38:09 -0000
@@ -144,12 +144,32 @@
     state->tls_enforce_tls = 0;
     state->tls_auth_only = 0;
     state->tls_context = 0;
+
+    /*
+     * With TLS wrapper mode, we run on a dedicated port and turn on TLS
+     * before actually speaking the SMTP protocol. This implies TLS enforce
+     * mode.
+     *
+     * With non-wrapper mode, TLS enforce mode implies that we don't advertise
+     * AUTH before the client issues STARTTLS.
+     */
+    if (!SMTPD_STAND_ALONE((state))) {
+ if (var_smtpd_tls_wrappermode) {
+    state->tls_use_tls = 1;
+    state->tls_enforce_tls = 1;
+ } else {
+    state->tls_use_tls = var_smtpd_use_tls | var_smtpd_enforce_tls;
+    state->tls_enforce_tls = var_smtpd_enforce_tls;
+ }
+ if (var_smtpd_tls_auth_only || state->tls_enforce_tls)
+    state->tls_auth_only = 1;
+    }
 #endif
 
 #ifdef USE_SASL_AUTH
     if (SMTPD_STAND_ALONE(state))
  var_smtpd_sasl_enable = 0;
-    if (var_smtpd_sasl_enable)
+    if (var_smtpd_sasl_enable && state->tls_auth_only == 0)
  smtpd_sasl_connect(state, VAR_SMTPD_SASL_OPTS, var_smtpd_sasl_opts);
 #endif
 

--
        Viktor.

Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the "Reply-To" header.

To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:
<mailto:[hidden email]?body=unsubscribe%20postfix-users>

If my response solves your problem, the best way to thank me is to not
send an "it worked, thanks" follow-up. If you must respond, please put
"It worked, thanks" in the "Subject" so I can delete these quickly.
Reply | Threaded
Open this post in threaded view
|

Re: 2.3.8->2.5.1 upgrade breaks dovecot SASL auth

Wietse Venema
Victor Duchovni:

> On Sun, Jun 15, 2008 at 10:13:48PM +0200, martin f krafft wrote:
>
> > Ok. Should I file a bug report for posterity anywhere? Or just ping
> > you again in x months? Please define x...
>
>
>   smtpd_sasl_auth_enable = yes
>   smtpd_tls_auth_only = yes
>   smtpd_sasl_tls_security_options = noanonymous
>   smtpd_sasl_security_options = mutual_auth $smtpd_sasl_tls_security_options
>
> You are asking for SASL only with TLS.
>
>   postfix/smtpd[14066]: fatal: no SASL authentication mechanisms
>
> but smtpd makes a SASL connection early before TLS is active. Try the
> patch below (based on 2.6, but should work with 2.5):

I appreciate that you're helping him out, but this leaves sasl-related
SMTPD_STATE members uninitialized with smtpd_tls_auth_only=yes and
without STARTTLS, and will segfault when those members are accessed.
For example, when it tries to format a Received: header, or upon
disconnect in vstring_free(state->sasl_reply).

The problem is not solved by duplicating/moving of non-trivial code
from smtpd.c into smtpd_state.c; this duplication/moving is guaranteed
to become a maintenance problem.

The purpose of smtpd_state_init() is to initialize. Any decisions
that depend on TLS or SASL usage MUST NOT be made in smtpd_state_init().
Such decisions must be made in the proper context.

If the solution were simple (i.e. no architectural change) I would
have posted it. I am not an unhelpful bastard.

        Wietse

> Index: src/smtpd/smtpd.c
> --- src/smtpd/smtpd.c 9 May 2008 00:27:26 -0000 1.1.1.4.2.1
> +++ src/smtpd/smtpd.c 15 Jun 2008 21:32:05 -0000
> @@ -3919,9 +3919,12 @@
>       */
>  #ifdef USE_SASL_AUTH
>      if (var_smtpd_sasl_enable
> - && strcmp(var_smtpd_sasl_tls_opts, var_smtpd_sasl_opts) != 0) {
> - smtpd_sasl_auth_reset(state);
> - smtpd_sasl_disconnect(state);
> + && (state->tls_auth_only
> +    || strcmp(var_smtpd_sasl_tls_opts, var_smtpd_sasl_opts) != 0)) {
> + if (state->tls_auth_only == 0) {
> +    smtpd_sasl_auth_reset(state);
> +    smtpd_sasl_disconnect(state);
> + }
>   smtpd_sasl_connect(state, VAR_SMTPD_SASL_TLS_OPTS,
>     var_smtpd_sasl_tls_opts);
>      }
> @@ -4431,28 +4434,6 @@
>      msg_info("connect from %s", state.namaddr);
>  
>      /*
> -     * With TLS wrapper mode, we run on a dedicated port and turn on TLS
> -     * before actually speaking the SMTP protocol. This implies TLS enforce
> -     * mode.
> -     *
> -     * With non-wrapper mode, TLS enforce mode implies that we don't advertise
> -     * AUTH before the client issues STARTTLS.
> -     */
> -#ifdef USE_TLS
> -    if (!SMTPD_STAND_ALONE((&state))) {
> - if (var_smtpd_tls_wrappermode) {
> -    state.tls_use_tls = 1;
> -    state.tls_enforce_tls = 1;
> - } else {
> -    state.tls_use_tls = var_smtpd_use_tls | var_smtpd_enforce_tls;
> -    state.tls_enforce_tls = var_smtpd_enforce_tls;
> - }
> - if (var_smtpd_tls_auth_only || state.tls_enforce_tls)
> -    state.tls_auth_only = 1;
> -    }
> -#endif
> -
> -    /*
>       * XCLIENT must not override its own access control.
>       */
>      xclient_allowed =
> Index: src/smtpd/smtpd_state.c
> --- src/smtpd/smtpd_state.c 16 Jan 2008 04:42:25 -0000 1.1.1.1
> +++ src/smtpd/smtpd_state.c 15 Jun 2008 21:38:09 -0000
> @@ -144,12 +144,32 @@
>      state->tls_enforce_tls = 0;
>      state->tls_auth_only = 0;
>      state->tls_context = 0;
> +
> +    /*
> +     * With TLS wrapper mode, we run on a dedicated port and turn on TLS
> +     * before actually speaking the SMTP protocol. This implies TLS enforce
> +     * mode.
> +     *
> +     * With non-wrapper mode, TLS enforce mode implies that we don't advertise
> +     * AUTH before the client issues STARTTLS.
> +     */
> +    if (!SMTPD_STAND_ALONE((state))) {
> + if (var_smtpd_tls_wrappermode) {
> +    state->tls_use_tls = 1;
> +    state->tls_enforce_tls = 1;
> + } else {
> +    state->tls_use_tls = var_smtpd_use_tls | var_smtpd_enforce_tls;
> +    state->tls_enforce_tls = var_smtpd_enforce_tls;
> + }
> + if (var_smtpd_tls_auth_only || state->tls_enforce_tls)
> +    state->tls_auth_only = 1;
> +    }
>  #endif
>  
>  #ifdef USE_SASL_AUTH
>      if (SMTPD_STAND_ALONE(state))
>   var_smtpd_sasl_enable = 0;
> -    if (var_smtpd_sasl_enable)
> +    if (var_smtpd_sasl_enable && state->tls_auth_only == 0)
>   smtpd_sasl_connect(state, VAR_SMTPD_SASL_OPTS, var_smtpd_sasl_opts);
>  #endif
>  
>
> --
> Viktor.
>
> Disclaimer: off-list followups get on-list replies or get ignored.
> Please do not ignore the "Reply-To" header.
>
> To unsubscribe from the postfix-users list, visit
> http://www.postfix.org/lists.html or click the link below:
> <mailto:[hidden email]?body=unsubscribe%20postfix-users>
>
> If my response solves your problem, the best way to thank me is to not
> send an "it worked, thanks" follow-up. If you must respond, please put
> "It worked, thanks" in the "Subject" so I can delete these quickly.
>
>

Reply | Threaded
Open this post in threaded view
|

Re: 2.3.8->2.5.1 upgrade breaks dovecot SASL auth

Victor Duchovni
On Sun, Jun 15, 2008 at 06:33:43PM -0400, Wietse Venema wrote:

> > You are asking for SASL only with TLS.
> >
> >   postfix/smtpd[14066]: fatal: no SASL authentication mechanisms
> >
> > but smtpd makes a SASL connection early before TLS is active. Try the
> > patch below (based on 2.6, but should work with 2.5):
>
> I appreciate that you're helping him out, but this leaves sasl-related
> SMTPD_STATE members uninitialized with smtpd_tls_auth_only=yes and
> without STARTTLS, and will segfault when those members are accessed.
> For example, when it tries to format a Received: header, or upon
> disconnect in vstring_free(state->sasl_reply).

Yes, oops, it is more subtle. Just one more try if I may. This time
with everything initialized as before (bail out at the last moment in
smtpd_sasl_connect(), afte all the SASL state fields are filled in).

Am I missing something else, is the solution simply too fragile?

Index: src/smtpd/smtpd.c
--- src/smtpd/smtpd.c 9 May 2008 00:27:26 -0000 1.1.1.4.2.1
+++ src/smtpd/smtpd.c 16 Jun 2008 01:37:54 -0000
@@ -3919,7 +3919,8 @@
      */
 #ifdef USE_SASL_AUTH
     if (var_smtpd_sasl_enable
- && strcmp(var_smtpd_sasl_tls_opts, var_smtpd_sasl_opts) != 0) {
+ && (state->tls_auth_only
+    || strcmp(var_smtpd_sasl_tls_opts, var_smtpd_sasl_opts) != 0)) {
  smtpd_sasl_auth_reset(state);
  smtpd_sasl_disconnect(state);
  smtpd_sasl_connect(state, VAR_SMTPD_SASL_TLS_OPTS,
@@ -4431,28 +4432,6 @@
     msg_info("connect from %s", state.namaddr);
 
     /*
-     * With TLS wrapper mode, we run on a dedicated port and turn on TLS
-     * before actually speaking the SMTP protocol. This implies TLS enforce
-     * mode.
-     *
-     * With non-wrapper mode, TLS enforce mode implies that we don't advertise
-     * AUTH before the client issues STARTTLS.
-     */
-#ifdef USE_TLS
-    if (!SMTPD_STAND_ALONE((&state))) {
- if (var_smtpd_tls_wrappermode) {
-    state.tls_use_tls = 1;
-    state.tls_enforce_tls = 1;
- } else {
-    state.tls_use_tls = var_smtpd_use_tls | var_smtpd_enforce_tls;
-    state.tls_enforce_tls = var_smtpd_enforce_tls;
- }
- if (var_smtpd_tls_auth_only || state.tls_enforce_tls)
-    state.tls_auth_only = 1;
-    }
-#endif
-
-    /*
      * XCLIENT must not override its own access control.
      */
     xclient_allowed =
Index: src/smtpd/smtpd_sasl_glue.c
--- src/smtpd/smtpd_sasl_glue.c 16 Jan 2008 04:42:25 -0000 1.1.1.1
+++ src/smtpd/smtpd_sasl_glue.c 16 Jun 2008 01:29:13 -0000
@@ -163,6 +163,10 @@
     state->sasl_username = 0;
     state->sasl_method = 0;
     state->sasl_sender = 0;
+    state->sasl_server = 0;
+
+    if (state->tls_auth_only && state->tls_context == 0)
+ return;
 
     /*
      * Set up a new server context for this connection.
Index: src/smtpd/smtpd_state.c
--- src/smtpd/smtpd_state.c 16 Jan 2008 04:42:25 -0000 1.1.1.1
+++ src/smtpd/smtpd_state.c 16 Jun 2008 01:30:50 -0000
@@ -144,6 +144,26 @@
     state->tls_enforce_tls = 0;
     state->tls_auth_only = 0;
     state->tls_context = 0;
+
+    /*
+     * With TLS wrapper mode, we run on a dedicated port and turn on TLS
+     * before actually speaking the SMTP protocol. This implies TLS enforce
+     * mode.
+     *
+     * With non-wrapper mode, TLS enforce mode implies that we don't advertise
+     * AUTH before the client issues STARTTLS.
+     */
+    if (!SMTPD_STAND_ALONE((state))) {
+ if (var_smtpd_tls_wrappermode) {
+    state->tls_use_tls = 1;
+    state->tls_enforce_tls = 1;
+ } else {
+    state->tls_use_tls = var_smtpd_use_tls | var_smtpd_enforce_tls;
+    state->tls_enforce_tls = var_smtpd_enforce_tls;
+ }
+ if (var_smtpd_tls_auth_only || state->tls_enforce_tls)
+    state->tls_auth_only = 1;
+    }
 #endif
 
 #ifdef USE_SASL_AUTH

--
        Viktor.

Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the "Reply-To" header.

To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:
<mailto:[hidden email]?body=unsubscribe%20postfix-users>

If my response solves your problem, the best way to thank me is to not
send an "it worked, thanks" follow-up. If you must respond, please put
"It worked, thanks" in the "Subject" so I can delete these quickly.
Reply | Threaded
Open this post in threaded view
|

Re: 2.3.8->2.5.1 upgrade breaks dovecot SASL auth

Wietse Venema
Victor Duchovni:

> On Sun, Jun 15, 2008 at 06:33:43PM -0400, Wietse Venema wrote:
>
> > > You are asking for SASL only with TLS.
> > >
> > >   postfix/smtpd[14066]: fatal: no SASL authentication mechanisms
> > >
> > > but smtpd makes a SASL connection early before TLS is active. Try the
> > > patch below (based on 2.6, but should work with 2.5):
> >
> > I appreciate that you're helping him out, but this leaves sasl-related
> > SMTPD_STATE members uninitialized with smtpd_tls_auth_only=yes and
> > without STARTTLS, and will segfault when those members are accessed.
> > For example, when it tries to format a Received: header, or upon
> > disconnect in vstring_free(state->sasl_reply).
>
> Yes, oops, it is more subtle. Just one more try if I may. This time
> with everything initialized as before (bail out at the last moment in
> smtpd_sasl_connect(), afte all the SASL state fields are filled in).
>
> Am I missing something else, is the solution simply too fragile?

As I wrote before, the purpose of smtpd_state_init() is to initialize.
It either sets something to zero, or it calls a function that
handles the domain-details concerning SASL, TLS, etc.  

Moving such domain-specific logic into smtpd_state_init() breaks
the structure of the program and introduces maintenance problems.

I will take time out of my schedule to fix this properly.

        Wietse

> Index: src/smtpd/smtpd.c
> --- src/smtpd/smtpd.c 9 May 2008 00:27:26 -0000 1.1.1.4.2.1
> +++ src/smtpd/smtpd.c 16 Jun 2008 01:37:54 -0000
> @@ -3919,7 +3919,8 @@
>       */
>  #ifdef USE_SASL_AUTH
>      if (var_smtpd_sasl_enable
> - && strcmp(var_smtpd_sasl_tls_opts, var_smtpd_sasl_opts) != 0) {
> + && (state->tls_auth_only
> +    || strcmp(var_smtpd_sasl_tls_opts, var_smtpd_sasl_opts) != 0)) {
>   smtpd_sasl_auth_reset(state);
>   smtpd_sasl_disconnect(state);
>   smtpd_sasl_connect(state, VAR_SMTPD_SASL_TLS_OPTS,
> @@ -4431,28 +4432,6 @@
>      msg_info("connect from %s", state.namaddr);
>  
>      /*
> -     * With TLS wrapper mode, we run on a dedicated port and turn on TLS
> -     * before actually speaking the SMTP protocol. This implies TLS enforce
> -     * mode.
> -     *
> -     * With non-wrapper mode, TLS enforce mode implies that we don't advertise
> -     * AUTH before the client issues STARTTLS.
> -     */
> -#ifdef USE_TLS
> -    if (!SMTPD_STAND_ALONE((&state))) {
> - if (var_smtpd_tls_wrappermode) {
> -    state.tls_use_tls = 1;
> -    state.tls_enforce_tls = 1;
> - } else {
> -    state.tls_use_tls = var_smtpd_use_tls | var_smtpd_enforce_tls;
> -    state.tls_enforce_tls = var_smtpd_enforce_tls;
> - }
> - if (var_smtpd_tls_auth_only || state.tls_enforce_tls)
> -    state.tls_auth_only = 1;
> -    }
> -#endif
> -
> -    /*
>       * XCLIENT must not override its own access control.
>       */
>      xclient_allowed =
> Index: src/smtpd/smtpd_sasl_glue.c
> --- src/smtpd/smtpd_sasl_glue.c 16 Jan 2008 04:42:25 -0000 1.1.1.1
> +++ src/smtpd/smtpd_sasl_glue.c 16 Jun 2008 01:29:13 -0000
> @@ -163,6 +163,10 @@
>      state->sasl_username = 0;
>      state->sasl_method = 0;
>      state->sasl_sender = 0;
> +    state->sasl_server = 0;
> +
> +    if (state->tls_auth_only && state->tls_context == 0)
> + return;
>  
>      /*
>       * Set up a new server context for this connection.
> Index: src/smtpd/smtpd_state.c
> --- src/smtpd/smtpd_state.c 16 Jan 2008 04:42:25 -0000 1.1.1.1
> +++ src/smtpd/smtpd_state.c 16 Jun 2008 01:30:50 -0000
> @@ -144,6 +144,26 @@
>      state->tls_enforce_tls = 0;
>      state->tls_auth_only = 0;
>      state->tls_context = 0;
> +
> +    /*
> +     * With TLS wrapper mode, we run on a dedicated port and turn on TLS
> +     * before actually speaking the SMTP protocol. This implies TLS enforce
> +     * mode.
> +     *
> +     * With non-wrapper mode, TLS enforce mode implies that we don't advertise
> +     * AUTH before the client issues STARTTLS.
> +     */
> +    if (!SMTPD_STAND_ALONE((state))) {
> + if (var_smtpd_tls_wrappermode) {
> +    state->tls_use_tls = 1;
> +    state->tls_enforce_tls = 1;
> + } else {
> +    state->tls_use_tls = var_smtpd_use_tls | var_smtpd_enforce_tls;
> +    state->tls_enforce_tls = var_smtpd_enforce_tls;
> + }
> + if (var_smtpd_tls_auth_only || state->tls_enforce_tls)
> +    state->tls_auth_only = 1;
> +    }
>  #endif
>  
>  #ifdef USE_SASL_AUTH
>
> --
> Viktor.
>
> Disclaimer: off-list followups get on-list replies or get ignored.
> Please do not ignore the "Reply-To" header.
>
> To unsubscribe from the postfix-users list, visit
> http://www.postfix.org/lists.html or click the link below:
> <mailto:[hidden email]?body=unsubscribe%20postfix-users>
>
> If my response solves your problem, the best way to thank me is to not
> send an "it worked, thanks" follow-up. If you must respond, please put
> "It worked, thanks" in the "Subject" so I can delete these quickly.
>
>