On 2010-12-12 at 03:10 +0000, David Woodhouse wrote:
> I've just pushed a set of patches to
> http://git.exim.org/users/dwmw2/exim.git
> git://git.exim.org/users/dwmw2/exim.git
First up: thanks, and sorry for not helping out this past week. I was
tied up in something and lacking Internet (or even cellular) coverage
for most of the time, only saw this today.
> They do the following:
>
> - Add Valgrind hooks to the store pools to aid debugging.
+1
> - Don't use config files as root if they're writeable by non-root
> users/groups. Including the Exim user/group.
This appears to be a mis-leading statement. Really, you're removing the
Exim user/group from being permitted owners by default. But if instead
we look at what you wrote as the goal, then this is awkward.
If I'm editing config files I'm doing so in a non-root svn checkout, so
that I avoid editing things as root with no audit trail. I will then,
as root, run some tests based upon those checkouts. That's now broken;
okay, it's "just" an extra cp, but it adds hoops to jump through.
OTOH, that shouldn't work right now, since I don't set CONFIGURE_OWNER.
But it clearly does.
Aren't there environments which distribute config files and data as a
non-privileged user, distinct from the user used for serving? None come
to mind right now, but I can well believe that one of the admin UI panel
interfaces for basic sysadmin will be creating the files as non-root.
> - Kill ALT_CONFIG_ROOT_ONLY as discussed, so only root can specify
> arbitrary files on the command line with the -C option. If the Exim
> user uses -C, or uses the -D option to set macros, then root privs
> will be dropped.
But if the Exim daemon is started as root with -C/-D, isn't this how the
changes are propagated into delivery instances, by having Exim re-exec
itself with the -MC* internal options and *also* passing along the -C/-D
options? Done with child_exec_exim().
How heavily has this change been tested in conjunction with doing actual
deliveries when the daemon was started as root with -C/-D ?
Eg, are there setups which use things like -DTLS and optionally enable
features this way from the cmdline with init-script config, rather than
direct Exim config?
For example, I can see someone testing out a new Mailman installation
while leaving the old one installed by running Exim for a day with
-DMAILMAN_HOME=/path/to/new/setup and doing so on just one machine in a
cluster of machines using a shared common Exim config.
> - Add a TRUSTED_CONFIG_PREFIX_FILE option. If set, it gives a filename
> for a file that contains prefix strings, like the ALT_CONFIG_PREFIX.
> Each line in that file specifies a prefix for config files which are
> to be trusted, and executed with root privilege if seen in the -C
> option, regardless of which user Exim is invoked by. As long as the
> config file is not writeable by anyone but root, of course.
+1
> - Set FD_CLOEXEC on SMTP sockets after forking to handle the connection.
The only gotcha I can think of is a non-issue; transport filter stdout
is read back by Exim and then passed to the SMTP socket from Exim,
rather than directly by the transport filter. Is there some other
subtle gotcha in one of the configuration corner cases?
I have a vague sense of unease about this one, but nothing strong enough
to lead to objection.
> The TRUSTED_CONFIG_PREFIX_FILE one wants a little more attention; I
> haven't properly tested it yet. But it's 3am so not right now...
5.30, I may well be missing something too. I hope my points are
coherent.
