I also would take a look at dmesg output. I have seen issues before
where a kernel OOPS at some point in the past was severely
constraining resources. Pretty much the only resolution, if that's
the case, will be a reboot.
I'm also recalling once a corrupted file in the hints databases. Try
stopping exim, wiping all of the hints files, and then starting again.
...Todd
On Fri, May 17, 2013 at 7:54 PM, Phil Pennock <pdp@???> wrote:
> On 2013-05-17 at 15:58 -0700, David Grant wrote:
>> 2013-05-17 14:15:10 [1495] 1UdRza-0000Nv-7W unable to set gid=1005 or
>> uid=1005 (euid=101): userforward router (recipient is user@???)
>> 2013-05-17 14:15:10 [1493] 1UdRza-0000Nv-7W internal problem in
>> userforward router (recipient is user@???): failure to transfer data
>> from subprocess: status=0100 readerror='Success'
>>
>> Which makes my problem look precisely like this old thread:
>>
>> http://www.gossamer-threads.com/lists/exim/users/6620
>>
>> However, I have both no_verify and the exim binary sticky bit set.
>>
>> Any suggestions on further troubleshooting much appreciated.
>
> Is the filesystem mounted without nosuid set?
>
> Is it a network file-system which might get upset and inconsistent if
> glared at?
>
> Have you added AppArmor restrictions, or their ilk, to the system?
> Something with capabilities(7) changed in the running environment?
>
> What paths to Exim are in use? There's the exim that was started, and
> the exim from "exim -bP exim_path" and if the paths differ you might not
> be checking the correct binaries.
>
> The problem claimed is not that the user can't access the files, or that
> the uid/gid can't be figured out frm the name, but that the gid/uid can
> not be set by the running process. That's entirely a kernel constraint.
> Which leads to "what could make that fail?". Well, it will fail if you
> lack permission to make the transition. You can lack permission if
> you're not root, or capabilities are preventing the action. As long as
> Exim is setuid root, and that can be seen in the filesystem at the time
> that the binary is invoked, then you'll be root by the time you get this
> far and permissions should drop fine.
>
> There are, separately, running modes which avoid use of setuid, outlined
> in the security chapter of The Exim Specification, which might have been
> used. Perhaps if something is trying to submit the message and
> immediately delivery, instead of submit for execution from a queue
> runner started by root, and someone has been not-quite-clever-enough
> when adjusting the security properties of the Exim install, you might
> see this? If so, setting "queue_only" in Exim should fix it.
>
> -Phil
>
> --
> ## List details at https://lists.exim.org/mailman/listinfo/exim-users
> ## Exim details at http://www.exim.org/
> ## Please use the Wiki with this list - http://wiki.exim.org/
--
The total budget at all receivers for solving senders' problems is $0.
If you want them to accept your mail and manage it the way you want,
send it the way the spec says to. --John Levine
