著者: Phil Pennock 日付: To: David Woodhouse CC: exim-dev 題目: Re: [exim-dev] What user should ${run...} in config file run as?
On 2010-12-13 at 00:34 +0000, David Woodhouse wrote: > Why the hell did this work anyway?
>
> cat > e.conf<<'EEE'
> spool_directory = ${run{/bin/chown root:root /var/spool/exim4/setuid}} ${run{/bin/chmod 4755 /var/spool/exim4/setuid}}
> EEE
> exim -Ce.conf -q
>
> Why are we invoking ${run...} directives in the config file as root? Why
> aren't we doing it as the Exim user?
It depends on the option. spool_directory is used as the default
directory for holding the Exim pid, so its value is needed for the
pid-file writing which happens before dropping root privs.
Most expansions are deferred until needed. Some are done early, in
readconf.c; uid and gid lists, spool_directory, log_file_path,
pid_file_path, localhost_number. Those are the main vulnerable options.
The others would be expand_string() from main(), up until privileges are
dropped in daemon.c:daemon_go(). Nothing in daemon_go() until that
point expands strings (the values used are non-expanded, and a good
argument for why there are expanded-vs-nonexpanded options).
main() will expand:
* gecos_name (if gecos_pattern is set)
* unknown_login (used as a name when the invoking uid is not in passwd)
* unknown_username (for the real name, per GECOS, when unknown_login
used)
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...} ?
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.
