dovecot - May 2015 - Failed running extprograms execute via socket - fatal recv(MSG_PEEK) failed disconnected

E.B. schreef op 5-5-2015 om 9:40:
> Sorrys. I decided to "make clean" and do new
"./configure" "make" and "make
> install" for dovecot first, then pigeonhole to make sure nothing is
off. After
> I do that I get same original error:
>
> dovecot: script: Fatal: recv(MSG_PEEK) failed: disconnected
>
> I went to go verifying in dovecot-pigeonhole that the two new patches are
there
> by manual inspect the source files you patched. I found only the first one,
not
> http://hg.rename-it.nl/dovecot-2.2-pigeonhole/rev/1eb0362461f0 maybe this
> because I downloaded a snap shot link at the top that wasn't built with
the
> 2nd change?
>
> I put 2nd change in manually (its only one liner) rebuilded and after
install.....
> same error with recv(MSG_PEEK)
>
> Thanks for ongoing help
Argh! Ok, that fix was a bit incomplete still:

http://hg.rename-it.nl/dovecot-2.2-pigeonhole/rev/89e0cef5b264

I wonder why my test didn't fail.

The extent of this bug is limited to using execute as a command (as 
opposed to using it as a test in an `if' statement) and not providing it 
with any input.

Regards,

Stephan.

> > I went to go verifying in dovecot-pigeonhole that the two new patches
are there
> > by manual inspect the source files you patched. I found only the first
one, not
> > http://hg.rename-it.nl/dovecot-2.2-pigeonhole/rev/1eb0362461f0 maybe
this
> > because I downloaded a snap shot link at the top that wasn't built
with the
> > 2nd change?
> >
> > I put 2nd change in manually (its only one liner) rebuilded and after
install.....
> > same error with recv(MSG_PEEK)
> >
> > Thanks for ongoing help
> 
> Argh! Ok, that fix was a bit incomplete still:
> 
> http://hg.rename-it.nl/dovecot-2.2-pigeonhole/rev/89e0cef5b264
Sorry I over-looking this. I just tested with this new fix. IT WORKS.
> I wonder why my test didn't fail.
> 
> The extent of this bug is limited to using execute as a command (as
> opposed to using it as a test in an `if' statement) and not providing
it
> with any input.
That's not matching to my environment. My script is calling execute
within a if block but not as a test but it IS providing input (but not get
any output if that matters)

if ...
{
   execute :input "test input" "test";
}

Only thing still unsolved is my other thread don't know why the exectued
script has no filesystem access? (like "touch /tmp/test" ignored no
error)

Also is the only different between direct and socket execute that with
socket I can run the script with more restricted owner and permissions?
Are there other differences?

On 5/5/2015 9:28 PM, E.B. wrote:
>> I wonder why my test didn't fail.
>>
>> The extent of this bug is limited to using execute as a command (as
>> opposed to using it as a test in an `if' statement) and not
providing it
>> with any input.
> That's not matching to my environment. My script is calling execute
> within a if block but not as a test but it IS providing input (but not get
> any output if that matters)
>
> if ...
> {
>    execute :input "test input" "test";
> }
Oh right, it happens when the script is not using the output of the
external program. If execute is not a test and the output from the
program is not used, there is no input stream to be read from the remote
service. Discussing what is input and output in this context is highly
confusing. :)
> Only thing still unsolved is my other thread don't know why the
exectued
> script has no filesystem access? (like "touch /tmp/test" ignored
no error)
So far, I still haven't seen your full config from `dovecot -n` output.
> Also is the only different between direct and socket execute that with
> socket I can run the script with more restricted owner and permissions?
> Are there other differences?
Either side could be run in a different chroot, if any.

Some of the environment variables such as SENDER and RECIPIENT are not
available in the service (that is a TODO item).

Regards,

Stephan.

> Only thing still unsolved is my other thread don't know why the
exectued
> script has no filesystem access? (like "touch /tmp/test" ignored
no error)
See my other post. Problem is systemd PrivateTmp=true hides anything
you do with /tmp from view by anyone else. Wondering if its in memory
or stashed away somewhere i can see it on the CLI