[Dovecot] Calling dovecot-lda from within Antispam pipe script (bash) seems to have no effect

[Ben Johnson]

Ben Morrow, thanks for your reply. I sent an update on the issue shortly
before you sent this reply. The issue is that the "vmail" user lacks the
rights required to read Dovecot's configuration file (at least that's
what I gather from the message obtained with strace).

But for the sake of thoroughness, I'll address each of your questions.

On 6/21/2013 4:01 PM, Ben Morrow wrote:
> At  1PM -0400 on 21/06/13 you (Ben Johnson) wrote:
>> On 6/20/2013 10:00 PM, Bob Miller wrote:
>>>
>>>> It really boils-down to the fact that I can call the following on the
>>>> command-line and it functions as expected:
>>>>
>>>> su vmail -c '/usr/lib/dovecot/deliver -a "sa-training at example.com" -d
>>>> "sa-training at example.com" -m "Training.SPAM" -p
>>>> "/tmp/sendmail-msg-25794.txt"'
>>>>
>>>> Yet, when I attempt to do the exact same thing from within the pipe
>>>> script that Dovecot Antispam calls, I receive exit code 75 from
>>>> deliver/dovecot-lda and absolutely nothing is logged, with exception of
>>>> the information of which I'm already aware (logged to syslog).
> 
> Can you change lda to always log to syslog? It's possible you're not
> seeing any logs because lda doesn't have permission to write to the log
> files.

I tried both options: setting LDA to log to syslog (and it logged plenty
of items, just nothing related to the pipe script's call to "deliver"),
and I tried specifying the log file locations, explicitly, with the
"log_path" and "info_log_path" directives within my "protocol lda {}"
stanza. Again, LDA wrote to the log files for other reasons, but nothing
relevant to the specific problem with "deliver" failing to deliver.

>>>> I am echo-ing $(whoami) just before calling "deliver" within the pipe
>>>> script and the output is "vmail". So, it's not as though the vmail user
>>>> somehow lacks the permissions required to send via dovecot-lda.
>>>
>>> There are two things that came to mind when I read your mail yesterday.
>>> They are the first things I check for when my commands work and my
>>> scripts don't.  
>>>
>>> The first is $PATH, I have found innumerable times when a script
>>> wouldn't run it was because it wasn't running with a fully loaded $PATH
>>> variable, and this is especially true if you are launching your script
>>> from cron.  To work around this I either put a PATH= at the top of the
>>> script, or I run the script as an argument to bash instead of using the
>>> executable bit (ie `bash /path/to/script.sh` instead of `./script.sh`)
>>> so the path is retained from the shell.  I decided against mentioning
>>> this yesterday because I noted you only used full paths in your script,
>>> which should also work to avoid this problem.
>>
>> All excellent insights.
>>
>> You can see the PATH value in my previous message on this subject (from
>> a few minutes ago); it matches the value that I see as "root" when I
>> print the PATH within the shell. So, that seems okay.
>>
>> Also, I took your good advice and eliminated the potential for the vmail
>> user's shell choice (which happens to be /bin/sh, *not* /bin/bash)
> 
> Are you on a system where they are different?

I believe that they are different in Debian. "ls" for these files
produces the following:

/bin/sh -> dash

/bin/bash

Even so, the script seems to function the same way with either
interpreter, so, this doesn't seem to be a factor.

>> to
>> affect the script's behavior. To do this I modified my antispam
>> configuration directives as such:
>>
>>   antispam_pipe_program = /bin/bash
> 
> It's generally better to write scripts in portable (or POSIX, at least)
> Bourne shell, rather than relying on features of particular shells.

That makes fine sense, and I'll take it under advisement and see if I
can modify the script to be as universal as possible.

> 
>>   antispam_pipe_program_args = /usr/bin/sa-learn-pipe.sh
>>   antispam_pipe_program_spam_arg = --spam
>>   antispam_pipe_program_notspam_arg = --ham
>>
>> Unfortunately, this change doesn't change the result at all; the call to
>> "deliver" still exits with status code 75.
>>
>>> The other thing I didn't mention was the permissions on the path
>>> to /usr/lib/dovecot/deliver (or any other path, really).  Directories
>>> with no world read/execute can prevent scripts from using files beneath
>>> them if they don't have permissions on each directory level in the path.
>>> I didn't mention this yesterday because you said you ran the script as
>>> vmail.  However, looking at your "su vmail -c" command, I remember some
>>> times when "su postrgres -c" didn't work when "su - postrgres" then
>>> running the command did.
>>
>> I have tried using "su vmail -c [...]", as well as "su vmail" and then
>> pasting the command into the shell. Both yield the same result.
> 
> Have you checked the group rights are the same in both cases? Is there
> any sort of MAC framework (SELinux or something similar) involved here?

Yes, the group rights should be the same, and no MAC framework is at play.

>> Also, there's no question that the vmail user is able to execute
>> dovecot-adm; if he weren't, then a) pasting the command into the shell
>> wouldn't work (and this does work), and b) I wouldn't be receiving exit
>> status code 75, which is unique to dovecot-adm (I assume that I'd
>> receive a more generic code, like 1, if it was a permissions problem).
> 
> 75 is a standard exit code from <sysexits.h> indicating temporary
> failure. Mail delivery programs need to be careful to distinguish
> between temporary and permanent failure, so they nearly always use the
> appropriate exit code.

Thank you for this informative tidbit!

>>
>>> Probably neither of these will be useful to you, but I mention them in
>>> hope that they trigger and idea or set you on an investigative path that
>>> proves helpful...
>>
>> Any help at all is useful! I really appreciate the time and thought you
>> put into your posts. I wish I felt closer to a solution... :(
>>
>> Please do reply if you have any additional thoughts. I'm at my wit's end
>> here!
> 
> As I believe someone else has already mentioned, the big hammer of
> strace is probably the most straightforward next step.

And it was what lead me to the root-cause (still looking for the
solution, however); right you gents were! THANK YOU!

> Ben
>