1 |
On 12/12/16 20:03, Sven Vermeulen wrote: |
2 |
> It's been a while that I did some Postfix work, which might be necessary to |
3 |
> debug this properly. The socket is owned by ddclient, is it possible that |
4 |
> "postdrop -r" input and/or output is redirected to a ddclient socket? From a |
5 |
> quick Google ddclient is shown as a Perl client, so some code scanning might |
6 |
> help to find out what the socket is about. |
7 |
|
8 |
Yes, ddclient is one long perl script. I am not a perl diver myself but |
9 |
it is not difficult to track down the code. The "sub" routine "sendmail" |
10 |
uses the subroutine "pipecmd" to run /usr/bin/sendmail with command line |
11 |
parameters and a few lines of input. Pipecmd uses the open function, |
12 |
prefixing the command ("sendmail" in this case) with a pipe: open(*FD, |
13 |
"| sendmail"). Ddclient doesn't attempt to read stdout from the |
14 |
sendmail/postdrop call so presumably this is postdrop trying to read the |
15 |
pipe passed to it by sendmail? |
16 |
|
17 |
Clearly sendmail is running in the ddclient domain (mta_sendmail_exec |
18 |
for some curious reason and not the sendmail interface) and presumably |
19 |
postdrop transitions to its own domain. This is where I think the |
20 |
problem lies and I am hoping it was my fault. At some point in trying to |
21 |
get sendmail to work I added |
22 |
"postfix_domtrans_user_mail_handler(ddclient_t)" but then found the |
23 |
answer was hiding in mta.if. This domtrans interface adds ddclient_t to |
24 |
the postfix_user_domtrans type attribute, which sesearch reveals to be |
25 |
one of the few ways of transitioning to the postfix_postdrop_t domain. |
26 |
That explains why postdrop has transitioned from sendmail (ddclient_t) |
27 |
and why it cannot access sendmail's pipe? |
28 |
|
29 |
I am testing the policy without the domtrans call and with my fingers |
30 |
crossed. |
31 |
|
32 |
Robert |