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
