Op 2/7/2017 om 5:04 AM schreef Richard Laager:> I'm getting lots of errors like this (possibly on every message
delivery):
>
> imap2 dovecot: lmtp(rlaager at wiktel.com): Error: OU02K+gQmFhUAwAAVtfydQ
> : sieve: binary save: failed to create temporary file:
> open(/var/lib/dovecot/sieve/junk-mail.svbin.ima
> p2.852.) failed: Permission denied (euid=500(vmail) egid=500(vmail)
> missing +w perm: /var/lib/dovecot/
> sieve, dir owned by 0:0 mode=0755)
>
> imap2 dovecot: lmtp(rlaager at wiktel.com): Error: OU02K+gQmFhUAwAAVtfydQ:
> sieve: The LDA Sieve plugin does not have permission to save global
> Sieve script binaries; global Sieve scripts like
> `/var/lib/dovecot/sieve/junk-mail.sieve' need to be pre-compiled using
> the sievec tool
>
> It's intentional in my setup that the vmail user can't write to the
> global sieve script directory. But it shouldn't need to, as those are
> already pre-compiled:
>
> rlaager at imap2:/var/lib/dovecot/sieve$ ls -la
> total 12
> drwxr-xr-x 2 root root 4096 Nov 29 22:27 .
> drwxr-xr-x 3 root root 4096 Feb 6 20:39 ..
> lrwxrwxrwx 1 root root 53 Sep 12 01:35 junk-mail.sieve ->
> /usr/share/wiktel-server-mail-backend/junk-mail.sieve
> -rw-r--r-- 1 root root 254 Nov 29 22:27 junk-mail.svbin
>
> rlaager at imap2:/var/lib/dovecot/sieve$ ls -la
> /usr/share/wiktel-server-mail-backend/junk-mail.sieve
> -rw-r--r-- 1 root root 124 Oct 31 09:34
> /usr/share/wiktel-server-mail-backend/junk-mail.sieve
>
> Note that the .svbin is from November, while the text version is from
> October. Even if something is looking at the date of the symlink,
that's
> from September.
>
> So the first question is... why is Dovecot trying to write the binary file?
Newer versions of Pigeonhole may use a different version of the compiled
binary format. So, for some upgrades it may be necessary to recompile.
> I dug into the Pigeonhole code... I think, but am certainly not sure,
> that lda_sieve_open() in
> pigeonhole/src/plugins/lda-sieve/lda-sieve-plugin.c is the relevant
> function calling lda_sieve_binary_save(). At the end of the function, it
> has:
>
> if (!recompile)
> lda_sieve_binary_save(srctx, sbin, script);
>
> This seems odd to me. Why is it trying to save in the
"!recompile" case?
> It seems like it should be saving in the "recompile" case. If
I'm
> reading this code right, recompile is set when it loads a corrupt sieve
> binary script and needs to recompile from text.
That part of the code is only relevant for binaries that are seen to be
corrupt at runtime, not when they are just perceived to be out-of-date.
I'll be reviewing this code soon anyway, because there are some known
problems with the up-to-date check itself (file time stamp race
condition). I'll be reviewing this as well.
Anyway, for now you should be helped by just manually recompiling.
Regards,
Stephan.