Re: [exim-dev] What user should ${run...} in config file run…

On Mon, 2010-12-13 at 01:23 -0500, Phil Pennock wrote:
> Taking the question from another angle: if you mean ${run...} should
> never be permitted to run as root and should always drop to Exim if the
> process is currently root, then:
> * good plan
> * but what about ${dlfunc...} ?

Hm, I briefly pondered ${perl...} but forgot about ${dlfunc...}.

> Making ${run...} drop privs but leaving ${dlfunc...} and ${perl...} is
> problematic. Should we make ${perl...} drop privs and ${dlfunc...} just
> fail if currently root? I think I favour this approach.

Doing ${run...} is easy because you can drop privs after the fork. For
the other two it's harder. You *could* use seteuid() but there's a
reason we don't use seteuid() in Exim. It's just a fig leaf, and real
root privs are just one seteuid(0) away. If we're doing that, we might
as well not bother.

One thing we might consider is forking to do the ${dlfunc...} and
${perl...} calls. That fixes an allocation problem we had with
${dlfunc...} anyway (see expand.c::3258).

If we fork and do those things in a separate process, then *that*
process can irrevocably give away its root privileges, and the result
can be passed back via a pipe.

Thinking about the compatibility issues... that change might cause
problems if people are somehow abusing ${perl...} and ${dlfunc...} to
set *global* state for the whole process, which is later used by other
calls. But I'm not even sure if that's *possible*, and even if it is I'm
inclined to suggest that we don't care. Wouldn't such a setup depend
heavily on the order of various expansions anyway?

If you have a ${dlfunc...} function that has an internal cache of some
kind so it's slow the first time and much faster next time, I suppose
*that* is a reasonable use of global state and would be made pessimal by
running each call in a separate process. But I'm still unconvinced I'd
care; the security improvement is worth that tradeoff.

--
dwmw2