Re: [exim] Alternative to the -D option

Góra strony
Delete this message
Reply to this message
Autor: Russell Stuart
Data:  
Dla: exim-users
Temat: Re: [exim] Alternative to the -D option
Thanks for the very fast response.

On Mon, 2011-10-10 at 03:08 -0400, Phil Pennock wrote:
> Use another config file which sets a couple of macros and then
> .include's the real config file, and then reference this new config file
> in the trusted list.


This is what I ended up doing.

> That way, the precise set of available macros is locked down to files
> controlled/owned by root, or the configure owner (which should _not_
> include the Exim run-time user).


As I discovered it isn't an ideal alternative. I lied. I had two
independent variables. On coming to the realisation using this method
to set N independent variables would need N! (N factorial) config files,
I decided it was time to eliminate one.

> Sorry, the old freedom made it far too easy to escalate privileges from
> the Exim run-time user to root (unless you built Exim as setuid to a
> dedicated user instead of root, per some of the pointers in "52.
> Security considerations").


Yes, well the old -D was a disaster waiting to happen, but you need a
replacement. There are lots of reasons people want tell exim to use
their config files in some special mode. My large message queues was
one. Sadly I passed in the message size with -DMAX_MESSAGE_SIZE=size.
It was a handy option but it had to go for now. I had another queue for
dealing with low priority messages which came into being when a massive
virus attack meant real messages weren't getting though. I haven't used
it in a while so it went as well. Others use macro's to feed messages
back into exim after some special processing has been done (eg spam,
virus checking). I now realise the WHITELISTED_D_MACROS thing was a
debian hack introduced for this reason.

I guess you are aware of this.