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