Sieve permissions issue following update

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Sieve permissions issue following update

David Gessel
I recently updated dovecot and my sieve filters stopped working.  Checking the logs I see:

Dec  9 00:09:59 mailhost dovecot: lda([hidden email]): Error: sieve: binary save: failed to create temporary file: open(/usr/local/etc/dovecot/sieve/10-move-spam.svbin.mailhost.domain.com.114.) failed: Permission denied (euid=5000(vmail) egid=5000(vmail) missing +w perm: /usr/local/etc/dovecot/sieve, we're not in group 6(mail), dir owned by 143:6 mode=0775)

Dec  9 00:09:59 mailhost dovecot: lda([hidden email]): Error: sieve: The LDA Sieve plugin does not have permission to save global Sieve script binaries; global Sieve scripts like `/usr/local/etc/dovecot/sieve/10-move-spam.sieve' need to be pre-compiled using the sievec tool


However this fairly clear advice on the failure seems to be contradicted by:

 # id vmail
uid=5000(vmail) gid=5000(vmail) groups=5000(vmail),6(mail)

?


dovecot-pigeonhole-0.4.6           =   up-to-date with index
dovecot2-2.2.15_1                  =   up-to-date with index


uname -a
FreeBSD host.domain.com 9.3-RELEASE FreeBSD 9.3-RELEASE #0 r268932: Mon Jul 21 15:51:38 PDT 2014     [hidden email]:/usr/obj/usr/src/sys/BARCELONA-13-08  amd64
Reply | Threaded
Open this post in threaded view
|

Re: Sieve permissions issue following update

Pascal Volk-3
On 12/09/2014 05:35 PM, David Gessel wrote:
> I recently updated dovecot and my sieve filters stopped working.  Checking the logs I see:
>
> Dec  9 00:09:59 mailhost dovecot: lda([hidden email]): Error: sieve: binary save: failed to create temporary file: open(/usr/local/etc/dovecot/sieve/10-move-spam.svbin.mailhost.domain.com.114.) failed: Permission denied (euid=5000(vmail) egid=5000(vmail) missing +w perm: /usr/local/etc/dovecot/sieve, we're not in group 6(mail), dir owned by 143:6 mode=0775)
>
> Dec  9 00:09:59 mailhost dovecot: lda([hidden email]): Error: sieve: The LDA Sieve plugin does not have permission to save global Sieve script binaries; global Sieve scripts like `/usr/local/etc/dovecot/sieve/10-move-spam.sieve' need to be pre-compiled using the sievec tool
>
>

As mentioned in the error message from your logs and in the wiki
<http://wiki2.dovecot.org/Pigeonhole/Sieve/Usage#Manually_Compiling_Sieve_Scripts>:

        To mitigate this problem, the administrator must manually
        pre-compile global scripts using the sievec command line tool.


Regards,
Pascal
--
The trapper recommends today: [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Sieve permissions issue following update

David Gessel
It has been running flawlessly for quite some time until the update.  

Global scripts were compiled:

/usr/local/etc/dovecot/sieve # ls
10-move-spam.sieve      10-move-spam.svbin

However, I ran sievec again and tried saving a modified script and got the same:

shiofuki dovecot: lda([hidden email]): Error: sieve: binary save: failed to create temporary file: open(/usr/local/etc/dovecot/sieve/10-move-spam.svbin.shiofuki.blackrosetech.com.96421.) failed: Permission denied (euid=5000(vmail) egid=5000(vmail) missing +w perm: /usr/local/etc/dovecot/sieve, we're not in group 6(mail), dir owned by 143:6 mode=0775)
Dec  9 11:30:39 shiofuki dovecot: lda([hidden email]): Error: sieve: The LDA Sieve plugin does not have permission to save global Sieve script binaries; global Sieve scripts like `/usr/local/etc/dovecot/sieve/10-move-spam.sieve' need to be pre-compiled using the sievec tool


I use Thomas Schmid's Sieve 0.2.3d add on to Thunderbird, if that might have any significance.

Compiling with sievec shouldn't change the permission error, which I still don't understand.




-------- Original Message --------
Subject: Re: Sieve permissions issue following update
From: Pascal Volk <[hidden email]>
To: Dovecot Mailing List <[hidden email]>
Date: Tue Dec 09 2014 20:45:00 GMT+0300 (Arabic Standard Time)

> On 12/09/2014 05:35 PM, David Gessel wrote:
>> I recently updated dovecot and my sieve filters stopped working.  Checking the logs I see:
>>
>> Dec  9 00:09:59 mailhost dovecot: lda([hidden email]): Error: sieve: binary save: failed to create temporary file: open(/usr/local/etc/dovecot/sieve/10-move-spam.svbin.mailhost.domain.com.114.) failed: Permission denied (euid=5000(vmail) egid=5000(vmail) missing +w perm: /usr/local/etc/dovecot/sieve, we're not in group 6(mail), dir owned by 143:6 mode=0775)
>>
>> Dec  9 00:09:59 mailhost dovecot: lda([hidden email]): Error: sieve: The LDA Sieve plugin does not have permission to save global Sieve script binaries; global Sieve scripts like `/usr/local/etc/dovecot/sieve/10-move-spam.sieve' need to be pre-compiled using the sievec tool
>>
>>
>
> As mentioned in the error message from your logs and in the wiki
> <http://wiki2.dovecot.org/Pigeonhole/Sieve/Usage#Manually_Compiling_Sieve_Scripts>:
>
> To mitigate this problem, the administrator must manually
> pre-compile global scripts using the sievec command line tool.
>
>
> Regards,
> Pascal
>
Reply | Threaded
Open this post in threaded view
|

Re: Sieve permissions issue following update

Pascal Volk-3
On 12/09/2014 07:50 PM, David Gessel wrote:

> It has been running flawlessly for quite some time until the update.  
>
> Global scripts were compiled:
>
> /usr/local/etc/dovecot/sieve # ls
> 10-move-spam.sieve      10-move-spam.svbin
>
> However, I ran sievec again and tried saving a modified script and got the same:
>
> shiofuki dovecot: lda([hidden email]): Error: sieve: binary save: failed to create temporary file: open(/usr/local/etc/dovecot/sieve/10-move-spam.svbin.shiofuki.blackrosetech.com.96421.) failed: Permission denied (euid=5000(vmail) egid=5000(vmail) missing +w perm: /usr/local/etc/dovecot/sieve, we're not in group 6(mail), dir owned by 143:6 mode=0775)
> Dec  9 11:30:39 shiofuki dovecot: lda([hidden email]): Error: sieve: The LDA Sieve plugin does not have permission to save global Sieve script binaries; global Sieve scripts like `/usr/local/etc/dovecot/sieve/10-move-spam.sieve' need to be pre-compiled using the sievec tool
>
>
> I use Thomas Schmid's Sieve 0.2.3d add on to Thunderbird, if that might have any significance.
>
> Compiling with sievec shouldn't change the permission error, which I still don't understand.
>
>
>> [TOFU snipped}

/usr/local/etc/dovecot/sieve is not the user's sieve_dir; see
<http://wiki2.dovecot.org/Pigeonhole/Sieve/Configuration>.

The GLOBAL sieve scripts (see your error message above) is manged by the
system administrator. Adnmins are using their favorite $EDITOR, the
chmod(1) and chown(1) commands. They don't need a ManageSieve client.


Regards,
Pascal
--
The trapper recommends today: [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Sieve permissions issue following update

David Gessel


-------- Original Message --------
Subject: Re: Sieve permissions issue following update
From: Pascal Volk <[hidden email]>
To: Dovecot Mailing List <[hidden email]>
Date: Wed Dec 10 2014 00:00:04 GMT+0300 (Arabic Standard Time)

> On 12/09/2014 07:50 PM, David Gessel wrote:
>> It has been running flawlessly for quite some time until the update.  
>>
>> Global scripts were compiled:
>>
>> /usr/local/etc/dovecot/sieve # ls
>> 10-move-spam.sieve      10-move-spam.svbin
>>
>> However, I ran sievec again and tried saving a modified script and got the same:
>>
>> shiofuki dovecot: lda([hidden email]): Error: sieve: binary save: failed to create temporary file: open(/usr/local/etc/dovecot/sieve/10-move-spam.svbin.shiofuki.blackrosetech.com.96421.) failed: Permission denied (euid=5000(vmail) egid=5000(vmail) missing +w perm: /usr/local/etc/dovecot/sieve, we're not in group 6(mail), dir owned by 143:6 mode=0775)
>> Dec  9 11:30:39 shiofuki dovecot: lda([hidden email]): Error: sieve: The LDA Sieve plugin does not have permission to save global Sieve script binaries; global Sieve scripts like `/usr/local/etc/dovecot/sieve/10-move-spam.sieve' need to be pre-compiled using the sievec tool
>>
>>
>> I use Thomas Schmid's Sieve 0.2.3d add on to Thunderbird, if that might have any significance.
>>
>> Compiling with sievec shouldn't change the permission error, which I still don't understand.
>>
>>
>>> [TOFU snipped}
>
> /usr/local/etc/dovecot/sieve is not the user's sieve_dir; see
> <http://wiki2.dovecot.org/Pigeonhole/Sieve/Configuration>.
>
> The GLOBAL sieve scripts (see your error message above) is manged by the
> system administrator. Adnmins are using their favorite $EDITOR, the
> chmod(1) and chown(1) commands. They don't need a ManageSieve client.
>

Pascal,

Thank you very much for your prompt assistance.  I apologize that I haven't been able to use your advice to sort out the issues, but I'm either not getting it or it is tangential to the problem I'm having.  I apologize if I haven't provided enough information.

90-sieve.conf's specification of those file locations for global and user scripts (relevant lines from the config below):

 sieve = ~/.dovecot.sieve
 sieve_dir = ~/sieve
 #sieve_global_dir =
 sieve_before = /usr/local/etc/dovecot/sieve/

I brought up the plugin only because only two things have touched any part of the dovecot/sieve configuration between "working" and "not working" states:

- An update using portmaster to dovecot2-2.2.15_1/dovecot-pigeonhole-0.4.6 and
- an edit via the Sieve plugin/Managesieve.  

One of the two has broken sieve. Unfortunately I did take note of the last working version of dovecot/dovecot-pigeonhole, but it could not be more than a few months old as I update ports fairly regularly and my last buildworld wasn't that long ago.

It is consistent with the errors and my understanding that user scripts are not the likely culprit: I included the information for the sake of completeness, which can now be dismissed.  Moving back to the logged warnings:

Error: sieve: binary save: failed to create temporary file: open(/usr/local/etc/dovecot/sieve/10-move-spam.svbin.shiofuki.blackrosetech.com.96421.) failed:

- this seems to me to indicate that sieve tried to write "10-move-spam.svbin.shiofuki.blackrosetech.com.96421" in the directory /usr/local/etc/dovecot/sieve/

Permission denied (euid=5000(vmail) egid=5000(vmail) missing +w perm: /usr/local/etc/dovecot/sieve

- I read this as sieve determining that "vmail" is not permitted to write to /usr/local/etc/dovecot/sieve

we're not in group 6(mail), dir owned by 143:6 mode=0775)

- and giving a very helpful bit of advice that "we're" not in group 6(mail) - which I'm reading as "vmail" not being in group "mail" - and that the target directory is owned by 143:6 0775.  The latter is consistent with the OS's reporting of the directory:

drwxrwxr-x   2 dovecot  mail      4B Dec  9 11:27 sieve

from /etc/group
mail:*:6:postfix,clamav,vscan,dovecot,vmail,spamd
dovecot:*:143:

IF I'm reading "we're" as "vmail" correctly, this is incorrect ("we're not in group 6(mail)).  vmail IS in group "mail" and group "mail" does have write permissions to /usr/local/etc/dovecot/sieve/
(group is rwx).  Perhaps "we're" now refers to another user?  I see from top (I realize this is unlikely):

96387 dovenull       1  20    0 29120K  6080K kqread  7   0:00   0.00% managesieve-login

As for the error

dovecot: lda([hidden email]): Error: sieve: The LDA Sieve plugin does not have permission to save global Sieve script binaries; global Sieve scripts like `/usr/local/etc/dovecot/sieve/10-move-spam.sieve' need to be pre-compiled using the sievec tool

The reported error is consistent with the previous - a newly minted permission problem that seems to have come with the update.  In this case the advice given about precompiling global scripts seems misplaced.  The script is compiled, as reported by the error immediately preceding (10-move-spam.svbin, the svbin suffix is added by the compilation process) and just to be sure I ran seivec again and #service dovecot restart without changing the error.

My inexpert intuition is that the latest update introduced a bug that is manifesting itself as a permission error.
Reply | Threaded
Open this post in threaded view
|

Re: Sieve permissions issue following update

Steffen Kaiser-9
In reply to this post by David Gessel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, 9 Dec 2014, David Gessel wrote:

> Global scripts were compiled:
>
> /usr/local/etc/dovecot/sieve # ls
> 10-move-spam.sieve      10-move-spam.svbin

> However, I ran sievec again and tried saving a modified script and got the same:

Actually this "ls" output and the last sentence does not indicate that the
Sieve script had been compiled: a) after changing 10-move-spam.sieve _and_
b) after the upgrade with the new Sieve tools.

Did _you_ _manually_ run:

cd /usr/local/etc/dovecot/sieve
rm 10-move-spam.svbin
sievec -D 10-move-spam.sieve

? And, is the sievec command displaying the Pigeonhole version you have
installed?

> -------- Original Message --------
> Subject: Re: Sieve permissions issue following update
> From: Pascal Volk <[hidden email]>
> To: Dovecot Mailing List <[hidden email]>
> Date: Tue Dec 09 2014 20:45:00 GMT+0300 (Arabic Standard Time)
>
>> On 12/09/2014 05:35 PM, David Gessel wrote:
>>> I recently updated dovecot and my sieve filters stopped working.  Checking the logs I see:
>>>
>>> Dec  9 00:09:59 mailhost dovecot: lda([hidden email]): Error: sieve: binary save: failed to create temporary file: open(/usr/local/etc/dovecot/sieve/10-move-spam.svbin.mailhost.domain.com.114.) failed: Permission denied (euid=5000(vmail) egid=5000(vmail) missing +w perm: /usr/local/etc/dovecot/sieve, we're not in group 6(mail), dir owned by 143:6 mode=0775)
>>>
>>> Dec  9 00:09:59 mailhost dovecot: lda([hidden email]): Error: sieve: The LDA Sieve plugin does not have permission to save global Sieve script binaries; global Sieve scripts like `/usr/local/etc/dovecot/sieve/10-move-spam.sieve' need to be pre-compiled using the sievec tool
>>
>> As mentioned in the error message from your logs and in the wiki
>> <http://wiki2.dovecot.org/Pigeonhole/Sieve/Usage#Manually_Compiling_Sieve_Scripts>:
>>
>> To mitigate this problem, the administrator must manually
>> pre-compile global scripts using the sievec command line tool.

- --
Steffen Kaiser
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQEVAwUBVIftyXz1H7kL/d9rAQLoLwf/bA1r7DR5AVxBUYT2R54eM8yALRJL3PLJ
IfZzIAaqeoZj5JtKR84F3ApDpLRYaLw2juXeEAELV+2GJXThDIEyLzbkhA3xwPOb
TViaaN1Htz3H+Scz3MDC/fxGAiNGNENGNj1GP4VJGM7DibrDOcd/pxePJjBvdKFS
YzhYxAng94UZqy23CZRvsbZiHnsh1ph2C3yXhxES3Ycvgg/ETBIz98DVTfJ74b4J
AEEUVnKIefWGun+WxWNgyI+p/aOSE3PyrHhmZx5ttgHhqU8KnmiKpWMaTUlpUmVb
U5ddZndFIERBfuDaGUdMsW0sDORJ/XswF6O/Gp3UF4NbFmNGQv8MZg==
=k9Fz
-----END PGP SIGNATURE-----
Reply | Threaded
Open this post in threaded view
|

Re: Sieve permissions issue following update [solved]

David Gessel


-------- Original Message --------
Subject: Re: Sieve permissions issue following update
From: Steffen Kaiser <[hidden email]>
To: David Gessel <[hidden email]>
Date: Wed Dec 10 2014 09:52:57 GMT+0300 (Arabic Standard Time)

>
> Actually this "ls" output and the last sentence does not indicate that the Sieve script had been compiled: a) after changing 10-move-spam.sieve _and_ b) after the upgrade with the new Sieve tools.

Good point.

>
> Did _you_ _manually_ run:
>
> cd /usr/local/etc/dovecot/sieve
> rm 10-move-spam.svbin

Ut oh... I did not rm the existing svbin.  

> sievec -D 10-move-spam.sieve
>
> ? And, is the sievec command displaying the Pigeonhole version you have installed?

And the -D directive is very useful, thanks:

# rm 10-move-spam.svbin
# sievec -D 10-move-spam.sieve
sievec(gessel): Debug: sieve: Pigeonhole version 0.4.6 (3e924b1b6c5c+) initializing
sievec(gessel): Debug: sieve: include: sieve_global is not set; it is currently not possible to include `:global' scripts.
sievec(gessel): Debug: sieve: file storage: Using script storage path: 10-move-spam.sieve
sievec(gessel): Debug: sieve: file script: Opened script `10-move-spam' from `10-move-spam.sieve'
sievec(gessel): Debug: sieve: Script `10-move-spam' from 10-move-spam.sieve successfully compiled

and watching the logs:
 dovecot: lda([hidden email]): sieve: msgid=<CAFOe2y4kDushW=u6_cN1JmsP1FF63BzJ5O8=[hidden email]>: stored mail into mailbox 'INBOX'

Success!

The permissions correction portion of the error below still seems wrong though, isn't it? And if so, a little misleading.

 Dec  9 00:09:59 mailhost dovecot: lda([hidden email]): Error: sieve: binary save: failed to create temporary file: open(/usr/local/etc/dovecot/sieve/10-move-spam.svbin.mailhost.domain.com.114.) failed: Permission denied (euid=5000(vmail) egid=5000(vmail) missing +w perm: /usr/local/etc/dovecot/sieve, we're not in group 6(mail), dir owned by 143:6 mode=0775)

Does it seem reasonable to let the port maintainer know to submit a request to include instructions in /usr/ports/UPDATING for recompiling global scripts when necessary (and how to do it)?  I checked before posting to the list and the last entry for sieve is this one:

20090828:
  AFFECTS: users of mail/dovecot and mail/dovecot-sieve
  AUTHOR: [hidden email]

  dovecot-sieve has been updated to a new implementation compatible with
  dovecot 1.2.x.  For details of what this means please refer to:

    http://wiki.dovecot.org/LDA/Sieve/Dovecot#Migration_from_CMUSieve
Reply | Threaded
Open this post in threaded view
|

Re: Sieve permissions issue following update [solved]

Steffen Kaiser-9
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, 11 Dec 2014, David Gessel wrote:

> and watching the logs:
> dovecot: lda([hidden email]): sieve: msgid=<CAFOe2y4kDushW=u6_cN1JmsP1FF63BzJ5O8=[hidden email]>: stored mail into mailbox 'INBOX'
>
> Success!

:-)

> The permissions correction portion of the error below still seems wrong though, isn't it? And if so, a little misleading.
>
> Dec  9 00:09:59 mailhost dovecot: lda([hidden email]): Error: sieve: binary save: failed to create temporary file: open(/usr/local/etc/dovecot/sieve/10-move-spam.svbin.mailhost.domain.com.114.) failed: Permission denied (euid=5000(vmail) egid=5000(vmail) missing +w perm: /usr/local/etc/dovecot/sieve, we're not in group 6(mail), dir owned by 143:6 mode=0775)

Well, the error is not wrong by itself. An user gets a new message, in
order to run the user's Sieve script, the LDA must load the sieve_before
script. This is out-of-sync currently, because of the upgrade, and hence
must be re-compiled and its binary form storred there.

One could argue, if:

a) in case of failure the binary should be written somewhere else, e.g. a
temporary location and re-compiled each time a message arrives, or into
the user's home dir, or ...
The current way tells the admin, that something is wrong.

b) sieve_before/after scripts chould be textually merged with user's
scripts and storred as one combined binary in the user's directory.
A change of a global script would impact all user scripts then, a message
to everyone would require quite a bit CPU.

> Does it seem reasonable to let the port maintainer know to submit a request to include instructions in /usr/ports/UPDATING for recompiling global scripts when necessary (and how to do it)?  I checked before posting to the list and the last entry for sieve is this one:

You could file a bug report in your distro's bug tracking software. If
these are standard locations - I mean, you did not changed the paths to
point somewhere else -, the upgrade should recompile shared Sieve scripts.

- --
Steffen Kaiser

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQEVAwUBVIlrdHz1H7kL/d9rAQLYBAf/bzt+3OLt6f236hd4N8fWOjo6dXJ5Cc5X
EJOHKcyMeHIzVSl2GkM6ckKkfRuIIjmK5DW3h36JhaIx7wh2nQJZnNPj0xCub6hK
4xE/HRoqfpnhW36Z5XvPZc656N8ut+gx0phnHxk11K1iV8kPHQsNy29d9213UWVP
yoVzaVLMBHYBRSMGIpU+10MRiSfFAbBce4mBWZ5Dt0bSUHXs5cDGRnRwH7HAvr6l
k2xeBmLf4oME7Y6/Ja75CWcHnnMlTMCp4J//zfHQnsrV7nFjEMiESU8MH3Z0IXqL
z4t9MVRdGWb17Sa4W22/LdainnxFcSKWR4dGX6bNu6qYLdApKXHzkQ==
=4TlD
-----END PGP SIGNATURE-----
Reply | Threaded
Open this post in threaded view
|

Re: Sieve permissions issue following update [!solved] :-(

David Gessel
Deleting the .svbin and recreating the .svbin script seems to have changed something, but didn't solve the whole problem (or not quite?).  I still read the error messages incorrectly, but more on that below.  I have a bit more data on the problem preventing sorting.

Sieve scripts are failing only for my auto-filing system for mailing lists which uses a sub-directory system, as in:

Lists/LowVol
Lists/Dovecot
etc.

(please note that this worked fine before the recent update to 0.4.6)

The scripts that fileinto a top level directory such as "Spam" work fine, the ones that fileinto a second level directory barf out.  All of them give the errors as below, but I see now that messages that are supposed to go to the lists directory ALSO give this error (which was a bit obfuscated):

"sieve: Execution of script /mail/blackrosetech.com/gessel//.dovecot.sieve;name=base failed, but implicit keep was successful (user logfile /mail/blackrosetech.com/gessel//.dovecot.sieve.log may reveal additional details)"

which tells me that
error: msgid=<[hidden email]>: failed to store into mailbox 'Lists/Libtech': Invalid mailbox name: Name must not have '/' characters.

(apparently a new requirement, because the script was definitely working before the update: much mail properly sorted).  Now to look up the new sub-directory delimiter: and "." works.  SOLVED for realz this time.

I believe this is true: depending on the dovecot storage mode, if you were successfully sieving into sub-directories delimited by "/" and it stopped working recently, try "." as the delimiter, so instead of

 fileinto "directory/subdirectory";

use

 fileinto "directory.subdirectory";




But I still get the permission errors in my logs.


Dec 11 10:21:11 shiofuki dovecot: lda([hidden email]): sieve: msgid=<[hidden email]>: stored mail into mailbox 'Junk'

Now I would argue that at this point both the first error and second error are factually wrong, though I could be misinterpreting things, and I suspect that some bug was introduced in the update I applied that is at the root of the problems as I haven't changed anything in my mail configuration: merely

Working fine
-update using portmaster -Rafd
Sieve is not working (with the errors above).

As for the reported errors, and I realize I may be completely reading this wrong, but I would parse the error messages as:

"Error: sieve: binary save: failed to create temporary file: open(/usr/local/etc/dovecot/sieve/10-move-spam.svbin.shiofuki.blackrosetech.com.60095.)"

-> This seems to indicate that sieve tried to save the file /usr/local/etc/dovecot/sieve/10-move-spam.svbin.shiofuki.blackrosetech.com.60095 and an error condition resulted which is being reported as not being able to save the file.

"failed: Permission denied"

-> This seems to indicate that sieve believes there is a permissioning problem.

"(euid=5000(vmail) egid=5000(vmail)"

-> I interpret this as reporting the user that sieve thinks should have permission to write to the target directory, which is what I would expect it to be.


"missing +w perm: /usr/local/etc/dovecot/sieve"

-> I could be totally wrong here, but I read this as sieve believing that the "vmail" user does not have write permission in the directory "/usr/local/etc/dovecot/sieve" which is incorrect.  I am not sure how this can be other than an sieve bug.

"we're not in group 6(mail)"

-> I'm reading "we're" as referring to user "vmail," which is also incorrect.  "vmail" is in group 6(mail).  I am not sure this can be other than a sieve bug.

"dir owned by 143:6 mode=0775"

-> This is correct: the directory /usr/local/etc/dovecot/sieve is owned by 143:6.  But user "vmail" is in group 6.

Next, dovecot reports an error on behalf of sieve.  This seems to be a continuation of the original error in that it also references what reads as the same "permission error" but comes to a different conclusion as to the cause of the error - that the global script needs to be compiled with sievec.

"dovecot: lda([hidden email]): Error: sieve: The LDA Sieve plugin does not have permission to save global Sieve script binaries; global Sieve scripts like `/usr/local/etc/dovecot/sieve/10-move-spam.sieve' need to be pre-compiled using the sievec tool"

"The LDA Sieve plugin does not have permission to save global Sieve script binaries"

-> this is the reported error condition - a permissions problem which is probably coming from sieve, but is incorrect.  Sieve does have permission to write to the folder.

"global Sieve scripts like `/usr/local/etc/dovecot/sieve/10-move-spam.sieve' need to be pre-compiled using the sievec tool"

-> I'm sure this is true, but since the underlying problem was not fixed by deleting the svbin file and recreating it with sievec, I think we can be confident that the prescription for the reported permission error will not fix the error.


Testing whether this is really a new and somewhat improperly reported permissioning problem, I changed the permissions of /usr/local/etc/dovecot/sieve/ to 777 and the errors went away.

I could be wrong, but I think this proves that:

1) The first warning from sieve about a permission error is correct but the proposed solution, that vmail should be in group 6 that owns the directory and does have write permission is wrong.  Sieve is now (since the update?) trying to write to the directory as some user other than "vmail" since vmail definitely is in group 6, group 6 has write permissions, and changing folder permissions to 777 from 775 makes the error go away.

2) The second warning from dovecot about a permission error is also correct, but the proposed solution, that scripts need to be complied, is not actually relevant.

Now to try to figure out what user sieve is operating as...

... and I haven't a clue other than vmail.


Is it possible that the new upgrade changed the name of the user that is being tested against the permissions of the target folder and that is causing sieve to fail?  Is it possible that the target folder for the temporary file that needs to be written has changed?   Perhaps that this temporary directory is called on during a "fileinto" command?  And perhaps that it isn't the global script that is the problem, but rather in user scripts?  (or that it was both, but the global script was fixed by deleting it and recompiling it)?

While it is reasonable to presume that there's an easy fix, or that I'm doing something stupid (especially as it doesn't seem that anyone else is having problems), there was a big change in the storage code between 0.4.3 and 0.4.4 and minor changes between 0.4.4 and 0.4.6.  I would have been running 0.4.3 before I updated based on the release dates to FreeBSD ports.


-David





-------- Original Message --------
Subject: Re: Sieve permissions issue following update [solved]
From: Steffen Kaiser <[hidden email]>
To: David Gessel <[hidden email]>
Date: Thu Dec 11 2014 13:01:23 GMT+0300 (Arabic Standard Time)

> On Thu, 11 Dec 2014, David Gessel wrote:
>
>> and watching the logs:
>> dovecot: lda([hidden email]): sieve: msgid=<CAFOe2y4kDushW=u6_cN1JmsP1FF63BzJ5O8=[hidden email]>: stored mail into mailbox 'INBOX'
>
>> Success!
>
> :-)
>
>> The permissions correction portion of the error below still seems wrong though, isn't it? And if so, a little misleading.
>
>> Dec  9 00:09:59 mailhost dovecot: lda([hidden email]): Error: sieve: binary save: failed to create temporary file: open(/usr/local/etc/dovecot/sieve/10-move-spam.svbin.mailhost.domain.com.114.) failed: Permission denied (euid=5000(vmail) egid=5000(vmail) missing +w perm: /usr/local/etc/dovecot/sieve, we're not in group 6(mail), dir owned by 143:6 mode=0775)
>
> Well, the error is not wrong by itself. An user gets a new message, in order to run the user's Sieve script, the LDA must load the sieve_before script. This is out-of-sync currently, because of the upgrade, and hence must be re-compiled and its binary form storred there.
>
> One could argue, if:
>
> a) in case of failure the binary should be written somewhere else, e.g. a temporary location and re-compiled each time a message arrives, or into the user's home dir, or ...
> The current way tells the admin, that something is wrong.

Something is definitely wrong, that's true, but the reported error is misleading.  It is very clear about what the problem is interpreted to be, which is just as clearly wrong.

>
> b) sieve_before/after scripts chould be textually merged with user's scripts and storred as one combined binary in the user's directory.
> A change of a global script would impact all user scripts then, a message to everyone would require quite a bit CPU.
>
>> Does it seem reasonable to let the port maintainer know to submit a request to include instructions in /usr/ports/UPDATING for recompiling global scripts when necessary (and how to do it)?  I checked before posting to the list and the last entry for sieve is this one:
>
> You could file a bug report in your distro's bug tracking software. If these are standard locations - I mean, you did not changed the paths to point somewhere else -, the upgrade should recompile shared Sieve scripts.
>
> -- Steffen Kaiser
>
Reply | Threaded
Open this post in threaded view
|

Re: Sieve permissions issue following update

Robert Blayzor
In reply to this post by Steffen Kaiser-9
On Dec 10, 2014, at 1:52 AM, Steffen Kaiser <[hidden email]> wrote:

>
>> Global scripts were compiled:
>>
>> /usr/local/etc/dovecot/sieve # ls
>> 10-move-spam.sieve      10-move-spam.svbin
>
>> However, I ran sievec again and tried saving a modified script and got the same:
>
> Actually this "ls" output and the last sentence does not indicate that the Sieve script had been compiled: a) after changing 10-move-spam.sieve _and_ b) after the upgrade with the new Sieve tools.
>
> Did _you_ _manually_ run:
>
> cd /usr/local/etc/dovecot/sieve
> rm 10-move-spam.svbin
> sievec -D 10-move-spam.sieve
>
> ? And, is the sievec command displaying the Pigeonhole version you have installed?


I've been following this thread and have been seeing a similar problem.  Dovecot 2.2.5 and pigeonhole-0.4.6

The problem I'm having is with "sieve_default" script that's in a directory users have no permission to:

  sieve = ~/.dovecot.sieve
  sieve_dir = ~/.sieve.d
  sieve_default = /etc/dovecot/sieve/default.sieve


My sieve.default only has "keep;" and I manually removed and compiled it.  

sievec(root): Debug: sieve: Pigeonhole version 0.4.6 (3e924b1b6c5c+) initializing
sievec(root): Debug: sieve: include: sieve_global is not set; it is currently not possible to include `:global' scripts.
sievec(root): Debug: sieve: file storage: Using script storage path: default.sieve
sievec(root): Debug: sieve: file script: Opened script `default' from `default.sieve'
sievec(root): Debug: sieve: Script `default' from default.sieve successfully compiled


ls -l
-rw-r--r--  1 root      wheel    6 Dec 31 15:54 default.sieve
-rw-r--r--  1 root      wheel  142 Dec 31 15:54 default.svbin


Yet, dovecot still tries to compile it under the user in that path.


Dec 31 15:55:11 dovecot: lda(fred): Error: sieve: binary save: failed to create temporary file: open(/etc/dovecot/sieve/default.svbin.localhost.87581.) failed: Permission denied (euid=1002(fred) egid=1002(fred) missing +w perm: /etc/dovecot/sieve, dir owned by 26:0 mode=0755)
Dec 31 15:55:11 dovecot: lda(fred): Error: sieve: The LDA Sieve plugin does not have permission to save global Sieve script binaries; global Sieve scripts like `/etc/dovecot/sieve/default.sieve' need to be pre-compiled using the sievec tool
Dec 31 15:55:11 dovecot: lda(fred): sieve: msgid=<[hidden email]>: stored mail into mailbox 'INBOX'


Ideas?
Reply | Threaded
Open this post in threaded view
|

Re: Sieve permissions issue following update

Robert Schetterer-2
see

Am 31.12.2014 um 17:05 schrieb Robert Blayzor:
> missing +w perm: /etc/dovecot/sieve, dir owned by 26:0 mode=0755)



Best Regards
MfG Robert Schetterer

--
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Franziskanerstraße 15, 81669 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein
Reply | Threaded
Open this post in threaded view
|

Re: Sieve permissions issue following update

Robert Blayzor
On Dec 31, 2014, at 11:18 AM, Robert Schetterer <[hidden email]> wrote:
> Am 31.12.2014 um 17:05 schrieb Robert Blayzor:
>> missing +w perm: /etc/dovecot/sieve, dir owned by 26:0 mode=0755)
>
>
>
> Best Regards
> MfG Robert Schetterer


Which is correct.  Dovecot-lda is running as the local user account, the default is not owned by them and the local user cannot write into the global/default sieve location.  The path has a precompiled default sieve script that the user does not own, it's a default.

So why is trying to compile the script (which is already compiled) in the default location?  That is the problem.

-Robert
Reply | Threaded
Open this post in threaded view
|

Re: Sieve permissions issue following update

Robert Schetterer-2
Am 31.12.2014 um 18:36 schrieb Robert Blayzor:

> On Dec 31, 2014, at 11:18 AM, Robert Schetterer <[hidden email]> wrote:
>> Am 31.12.2014 um 17:05 schrieb Robert Blayzor:
>>> missing +w perm: /etc/dovecot/sieve, dir owned by 26:0 mode=0755)
>>
>>
>>
>> Best Regards
>> MfG Robert Schetterer
>
>
> Which is correct.  Dovecot-lda is running as the local user account, the default is not owned by them and the local user cannot write into the global/default sieve location.  The path has a precompiled default sieve script that the user does not own, it's a default.
>
> So why is trying to compile the script (which is already compiled) in the default location?  That is the problem.
>
> -Robert
>

However logs mostly tells truth , you have a permission problem
Happy New Year


Best Regards
MfG Robert Schetterer

--
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Franziskanerstraße 15, 81669 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein
Reply | Threaded
Open this post in threaded view
|

Re: Sieve permissions issue following update

Stephan Bosch-2
In reply to this post by Robert Blayzor
On 12/31/2014 5:05 PM, Robert Blayzor wrote:
> On Dec 10, 2014, at 1:52 AM, Steffen Kaiser <[hidden email]> wrote:
>
> I've been following this thread and have been seeing a similar problem.  Dovecot 2.2.5 and pigeonhole-0.4.6
>

> Yet, dovecot still tries to compile it under the user in that path.
>
>
> Dec 31 15:55:11 dovecot: lda(fred): Error: sieve: binary save: failed to create temporary file: open(/etc/dovecot/sieve/default.svbin.localhost.87581.) failed: Permission denied (euid=1002(fred) egid=1002(fred) missing +w perm: /etc/dovecot/sieve, dir owned by 26:0 mode=0755)
> Dec 31 15:55:11 dovecot: lda(fred): Error: sieve: The LDA Sieve plugin does not have permission to save global Sieve script binaries; global Sieve scripts like `/etc/dovecot/sieve/default.sieve' need to be pre-compiled using the sievec tool
> Dec 31 15:55:11 dovecot: lda(fred): sieve: msgid=<[hidden email]>: stored mail into mailbox 'INBOX'

Could you enable mail_debug? That should show why it is trying to
recompile the Sieve script.

Regards,

Stephan.
Reply | Threaded
Open this post in threaded view
|

Re: Sieve permissions issue following update

Robert Blayzor
On Jan 1, 2015, at 8:10 AM, Stephan Bosch <[hidden email]> wrote:
>
> Could you enable mail_debug? That should show why it is trying to
> recompile the Sieve script.


Well, that it does!  And it's saying the script is "not up to date" and tries to recompile it.  However, I'm not sure why it would say it's NOT up to date, it most certainly was manually compiled by me and not touched afterwards.  Would commented likes, starting with "#" in the script have anything to do with it?


Jan 01 13:32:30 lda(rt): Debug: sieve: file storage: Using script storage path: /etc/dovecot/sieve/default.sieve
Jan 01 13:32:30 lda(rt): Debug: sieve: file script: Opened script `default' from `/etc/dovecot/sieve/default.sieve'
Jan 01 13:32:30 lda(rt): Debug: sieve: Using the following location for user's Sieve script: /etc/dovecot/sieve/default.sieve
Jan 01 13:32:30 lda(rt): Debug: sieve: Loading script /etc/dovecot/sieve/default.sieve
Jan 01 13:32:30 lda(rt): Debug: sieve: Script binary /etc/dovecot/sieve/default.svbin is not up-to-date
Jan 01 13:32:30 lda(rt): Debug: sieve: Script `default' from /etc/dovecot/sieve/default.sieve successfully compiled
Jan 01 13:32:30 lda(rt): Error: sieve: binary save: failed to create temporary file: open(/etc/dovecot/sieve/default.svbin.dogpile.devnull.us.679.) failed: Permission denied (euid=1002(rt) egid=1002(rt) missing +w perm: /etc/dovecot/sieve, dir owned by 26:0 mode=0755)
Reply | Threaded
Open this post in threaded view
|

Re: Sieve permissions issue following update

Gene Heskett
On Thursday 01 January 2015 08:36:40 Robert Blayzor did opine
And Gene did reply:

> On Jan 1, 2015, at 8:10 AM, Stephan Bosch <[hidden email]> wrote:
> > Could you enable mail_debug? That should show why it is trying to
> > recompile the Sieve script.
>
> Well, that it does!  And it's saying the script is "not up to date" and
> tries to recompile it.  However, I'm not sure why it would say it's
> NOT up to date, it most certainly was manually compiled by me and not
> touched afterwards.  Would commented likes, starting with "#" in the
> script have anything to do with it?
>
>
> Jan 01 13:32:30 lda(rt): Debug: sieve: file storage: Using script
> storage path: /etc/dovecot/sieve/default.sieve Jan 01 13:32:30
> lda(rt): Debug: sieve: file script: Opened script `default' from
> `/etc/dovecot/sieve/default.sieve' Jan 01 13:32:30 lda(rt): Debug:
> sieve: Using the following location for user's Sieve script:
> /etc/dovecot/sieve/default.sieve Jan 01 13:32:30 lda(rt): Debug:
> sieve: Loading script /etc/dovecot/sieve/default.sieve Jan 01 13:32:30
> lda(rt): Debug: sieve: Script binary /etc/dovecot/sieve/default.svbin
> is not up-to-date Jan 01 13:32:30 lda(rt): Debug: sieve: Script
> `default' from /etc/dovecot/sieve/default.sieve successfully compiled
> Jan 01 13:32:30 lda(rt): Error: sieve: binary save: failed to create
> temporary file:
> open(/etc/dovecot/sieve/default.svbin.dogpile.devnull.us.679.) failed:
> Permission denied (euid=1002(rt) egid=1002(rt) missing +w perm:
> /etc/dovecot/sieve, dir owned by 26:0 mode=0755)

Obviously, the last 3 lines are showing a perms problem.

Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS
Reply | Threaded
Open this post in threaded view
|

Re: Sieve permissions issue following update

Robert Blayzor
On Jan 1, 2015, at 9:12 AM, Gene Heskett <[hidden email]> wrote:
>
> Obviously, the last 3 lines are showing a perms problem.


Yes, I know it's a permissions problem.  But there should be NO permissions problem as it should not be trying to recompile the script.  The script was already pre-compiled and has not changed. (though it thinks it's "out of date" ?).  The only "fix" would be to chmod 777 the directory where the default script is so that EVERYONE could compile it at the location. (even though it shouldn't need to be because it was already precompiled)  But that would be rather silly now, wouldn't it?

These are default sieve scripts that are not in the users homedir, so they have no permission to compile and write them in a directory they don't own.

-Robert
Reply | Threaded
Open this post in threaded view
|

Re: Sieve permissions issue following update

Stephan Bosch-2
In reply to this post by Robert Blayzor
On 1/1/2015 2:36 PM, Robert Blayzor wrote:

> On Jan 1, 2015, at 8:10 AM, Stephan Bosch <[hidden email]> wrote:
>> Could you enable mail_debug? That should show why it is trying to
>> recompile the Sieve script.
>
> Well, that it does!  And it's saying the script is "not up to date" and tries to recompile it.  However, I'm not sure why it would say it's NOT up to date, it most certainly was manually compiled by me and not touched afterwards.  Would commented likes, starting with "#" in the script have anything to do with it?
>
>
> Jan 01 13:32:30 lda(rt): Debug: sieve: file storage: Using script storage path: /etc/dovecot/sieve/default.sieve
> Jan 01 13:32:30 lda(rt): Debug: sieve: file script: Opened script `default' from `/etc/dovecot/sieve/default.sieve'
> Jan 01 13:32:30 lda(rt): Debug: sieve: Using the following location for user's Sieve script: /etc/dovecot/sieve/default.sieve
> Jan 01 13:32:30 lda(rt): Debug: sieve: Loading script /etc/dovecot/sieve/default.sieve
> Jan 01 13:32:30 lda(rt): Debug: sieve: Script binary /etc/dovecot/sieve/default.svbin is not up-to-date
> Jan 01 13:32:30 lda(rt): Debug: sieve: Script `default' from /etc/dovecot/sieve/default.sieve successfully compiled
> Jan 01 13:32:30 lda(rt): Error: sieve: binary save: failed to create temporary file: open(/etc/dovecot/sieve/default.svbin.dogpile.devnull.us.679.) failed: Permission denied (euid=1002(rt) egid=1002(rt) missing +w perm: /etc/dovecot/sieve, dir owned by 26:0 mode=0755)

Hmm. This smells like a bug. I notice that your modification times of
the .sieve and .svbin file are exactly the same (that is somewhat
unusual). I'm looking at a potential bug that would explain your problem.

To confirm, could you try running sievec again, so that the .svbin is
actually newer than the .sieve?

Regards,

Stephan.
Reply | Threaded
Open this post in threaded view
|

Re: Sieve permissions issue following update

Robert Blayzor
On Jan 1, 2015, at 9:50 AM, Stephan Bosch <[hidden email]> wrote:
>
> Hmm. This smells like a bug. I notice that your modification times of
> the .sieve and .svbin file are exactly the same (that is somewhat
> unusual). I'm looking at a potential bug that would explain your problem.
>
> To confirm, could you try running sievec again, so that the .svbin is
> actually newer than the .sieve?


Sorry about that.  ls -l was only showing minutes the actual file mtime *is* newer:

ls -l
-rw-r--r--  1 root  wheel  168 Jan  1 13:37 default.sieve
-rw-r--r--  1 root  wheel  300 Jan  1 13:37 default.svbin

stat -f %Sm default.sieve
Jan  1 13:37:42 2015

stat -f %Sm default.svbin
Jan  1 13:37:51 2015


I did just run it again... same problem:

-rw-r--r--  1 root  wheel  168 Jan  1 13:37 default.sieve
-rw-r--r--  1 root  wheel  300 Jan  1 14:55 default.svbin

Jan  1 14:56:52 dovecot: lda(fred): Error: sieve: binary save: failed to create temporary file: open(/etc/dovecot/sieve/default.svbin.localhost.1435.) failed: Permission denied (euid=1002(fred) egid=1002(fred) missing +w perm: /etc/dovecot/sieve, dir owned by 26:0 mode=0755)
Jan  1 14:56:52 dovecot: lda(fred): Error: sieve: The LDA Sieve plugin does not have permission to save global Sieve script binaries; global Sieve scripts like `/etc/dovecot/sieve/default.sieve' need to be pre-compiled using the sievec tool


TIA
Reply | Threaded
Open this post in threaded view
|

Re: Sieve permissions issue following update

Robert Blayzor
On Jan 1, 2015, at 9:58 AM, Robert Blayzor <[hidden email]> wrote:
>
>> Hmm. This smells like a bug. I notice that your modification times of
>> the .sieve and .svbin file are exactly the same (that is somewhat
>> unusual). I'm looking at a potential bug that would explain your problem.
>>
>> To confirm, could you try running sievec again, so that the .svbin is
>> actually newer than the .sieve?


If it makes any difference at all...  I only see this using "dovecot-lda".  If I change my Exim transport to use Dovecot's LMTP, I do not see this problem.

For the record also, the script DOES still execute (the compiled version that exists), even after the error...

--
Robert
12