[Philip Hazel]
> On Tue, 5 Aug 2003, Harald Meland wrote:
>
>> > During the time that the program is not running as root, any *other*
>> > program that is running as that euid will have access to the process,
>> > and could in principle modify the contents of its address space.
>>
>> ... or simply seteuid(2) back to root by themselves.
>
> Sorry, you misunderstand me. I didn't mean another program that was
> run from Exim. I meant an entirely independent other program running
> under the non-root uid.
Ahh, I see. I agree that that sounds troublesome.
>> I frankly can't see how the functionality I am looking to implement
>> (which was present in earlier Exim versions), can be done without
>> either
>>
>> 1) using seteuid(2) or
>> 2) increasing the number of processes, and how much they need to
>> communicate between them, involved in routing addresses.
>
> I agree, which is why the functionality is no longer there. Exim 4 has
> now been in the field for about 18 months, and this is the first time
> that anybody has raised this issue. For that reason, I cannot believe
> that it is a critical one. Nevertheless, I regret that this is causing
> you problems. However, I'm not sure where we go from here...
Well, even though this functionality is critical to us today, it won't
be critical forever -- as we've just started the process of migrating
our users to a non-home-directory-referencing mail system.
However, most users are still residing in the old system, and some
will likely continue to do so as long as we allow them to (due to
their heavy use of e.g. procmail etc.). Hence, we really need
'require_files' to work the way it used to.
The upshot of all this is that I've now ported the sete[ug]id parts of
match_exists from Exim 3 to check_files in Exim 4, which seems to work
nicely in the way that it will deliver user's mail. :-)
As I now have realized that this solution is indeed not secure
(although it's no worse than the situation we've had until now, with
Exim < 4), I'll have a look at implementing this by fork()ing out a
separate process, doing plain set[ug]id() before stat() etc. there,
and reporting the result back to the mother process.
If and when I get around to that, I'll post the patch here.
--
Harald
