Am 08.10.2013 um 23:17 schrieb Phil Pennock <pdp@???>:
> On 2013-10-08 at 19:16 +0000, Viktor Dukhovni wrote:
>> On Tue, Oct 08, 2013 at 07:47:11PM +0200, Axel Rau wrote:
>>
>>>> Whose "~"? Why should that work? Is there a system-wide postgresql
>>>> configuration?
>>>
>>> It's the home of the client. In this case the exim user.
>>
>> Phil, is it reasonable to expect that in running Exim processes,
>> libraries searching for configuration files in user home directories
>> should expect to find either $HOME=~exim or getpwuid(getuid())->pw_dir=~exim?
>
> In theory: yes I'd love that to be reasonable.
>
> In practice: no, and frankly this situation is the sort of moment when I
> put my head in my hands and wonder why I don't run Postfix instead, with
> clearly separate binaries for different roles instead of a configuration
> file where the "main" settings can be hard to reason about root-vs-exim.
>
> (Then I look at my setup, realise I couldn't reproduce with Postfix, and
> stick with Exim's flexibility :) ... but that doesn't keep this from
> being something that Exim is behind in).
>
>> MTAs are complex, and tend to run with different identities at
>> different times (e.g. when delivering mail to commands in .forward
>> files, ...) and I don't know whether it is reasonable to expect a constant
>> $HOME in a running Exim process. Since my expertise is with Postfix and
>> OpenSSL, not Exim, I'll leave that question to others.
>
> $HOME is set up for external commands, being in the list of manipulated
> environment variables, and is set according to whether or not a home
> directory has been defined in the evaluation context; most commonly,
> this will be check_local_user implicitly doing so.
>
> So we're dealing here with a getpwuid(getuid())->pw_dir situation. And
> this depends entirely upon what part of the configuration file the
> string expansion is in: it's the invoking user, at time of evaluation.
> As much as possible, that should be the "exim" user, but there are still
> some things evaluated as root.
>
> Checking the postgres source (it's a bad sign that I have a copy of
> their git repo laying around, right?) I see they're using geteuid(), so
> this isn't an effective/real conflict.
>
> Axel, which directive are you using the pgsql lookup in please?
It's in the SMTP transport:
tpda_delivery_action = ${lookup pgsql {SELECT * FROM record_Delivery( \
'${quote_pgsql:$sender_address_domain}', '${quote_pgsql:${lc:$sender_address_local_part}}', \
'${quote_pgsql:$tpda_delivery_domain}', '${quote_pgsql:${lc:$tpda_delivery_local_part}}', \
'${quote_pgsql:$tpda_delivery_ip}', '${quote_pgsql:${lc:$tpda_delivery_fqdn}}', \
'${quote_pgsql:$message_exim_id}', '${quote_pgsql:$tpda_delivery_confirmation}')}}
>
> The pgsql_servers setting should just be storing the definitions away
> for later reference, and then the first pgsql lookup using that server
> definition should evaluate with the current runtime user. There should
> be ... very little where that is done as root. I'm concerned that it
> happened at all.
Axel
---
PGP-Key:29E99DD6 ☀ +49 151 2300 9283 ☀ computing @ chaos claudius
