Re: [exim] Spurious permission denied error

On Tue, Apr 28, 2020 at 11:17:09AM +0100, Andrew C Aitchison wrote:
>
> On 27/04/2020 20:52, Russell King via Exim-users wrote:
> >2020-04-27 20:36:15 1jT9Y7-0003B4-Mf <= patchd@???
> U=patchd P=local S=1535
> >2020-04-27 20:36:15 1jT9Y7-0003B4-Mf H=pandora.armlinux.org.uk
> [xxxx:xxxx:xxxx:xxxx:214:fdff:fe10:1be6] Permission denied
> >2020-04-27 20:36:17 1jT9Y7-0003B4-Mf => user@??? R=smart_route
> T=remote_smtp H=pandora.armlinux.org.uk
> [xxxx:xxxx:xxxx:xxxx:214:fdff:fe10:1be6]
> X=TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256 CV=yes A=fixed_cram C="250 OK
> id=1jT9Y8-0004ff-Qf"
> >
> >My guess is that there is some file that exim can't access while
> >attempting to send to pandora, but I think working out what is
> >going to be very hard (I guess debug isn't allowed from non-root
> >users?)
>
> ... and followed up with:
> >and grepping the strace output for errors:
> >
> >19841 openat(AT_FDCWD, "/var/spool/exim4//input//1jTM7j-0005A1-Na-D",
> >O_RDWR|O_CREAT|O_EXCL|O_LARGEFILE, 0640) = -1 EACCES (Permission denied)
> >19841 openat(AT_FDCWD, "/var/log/exim4/mainlog",
> >O_WRONLY|O_APPEND|O_LARGEFILE|O_CLOEXEC) = -1 EACCES (Permission denied)
> >19841 openat(AT_FDCWD, "/var/log/exim4/paniclog",
> >O_WRONLY|O_APPEND|O_LARGEFILE|O_CLOEXEC) = -1 EACCES (Permission denied)
> >
> >So we're not getting anywhere near delivery (which is where the permission
> >denied error is happening).
>
> Are you sure that the permission denied error is happening near delivery ?
> The timestamps suggest that the permission denied is nearer message input
> (<=) than delivery (=>).

I'm quite sure that it's delivery - see my reply to Jeremy, where the
problem has now been located, and you will likely be surprised by its
cause. It has nothing to do with local file permissions at all!

*Sigh* the reply-to-list thing gets me again, and I'm getting fed up with
having to re-edit the headers or rewrite the reply each time I reply to
an email on this mailing list. Reply-to-list is just too foreign to me,
being a kernel developer where reply-to-all is mandatory.

--
Russell King