- that it calls (so that the whole sequence uses the same config file). If
- it's running as \/exim/\ when it does this, all is well. However, if it
- happens as a consequence of a non-privileged user running \%autoreply%\,
- the called Exim gives up its root privilege. Then it can't write to the
- spool.
-
- This means that you can't use -C (even as \/root/\) to run an instance of
- Exim that is going to try to run \%autoreply%\ from a process that is
- neither \/root/\ nor \/exim/\. Because of the architecture of Exim (using
- re-execs to regain privilege), there isn't any way round this
- restriction. Therefore, the only way you can make this scenario work is
- to run the \%autoreply%\ transport as \/exim/\ (that is, the user that
- owns the Exim spool files). This may be satisfactory for autoreplies
- that are essentially system-generated, but of course is no good for
- autoreplies from unprivileged users, where you want the \%autoreply%\
- transport to be run as the user. To get that to work with an alternate
- configuration, you'll have to use two Exim binaries, with different
- configuration file names in each. See S001 for a script that patches
- the configuration name in an Exim binary.
+ that it calls (so that the whole sequence uses the same config file).
+ However, Exim gives up its root privilege if any user except \/root\/
+ passes a -C option to use a non-default configuration file, and that
+ includes the case where Exim re-execs itself to regain root privilege.
+ Thus it can't write to the spool.
+
+ The fix for this is to use the \\TRUSTED_CONFIG_LIST\\ build-time
+ option. This defines a file containing a list of 'trusted' prefixes for
+ configuration files. Any configuration file specified with -C, if it
+ matches a prefix listed in that file, will be used without dropping root
+ privileges (as long as it is not writeable by a non-root user).
git://git.exim.org / users / jgh / exim.git / blobdiff