On 2017-08-18, Patrick Pfeifer via Exim-users <[email protected]> wrote:
> On 2017-08-18 20:12, Jeremy Harris wrote:
>> First, you don't need to copy exim-dev as well as exim-users.
>> Devs will be reading both.
> Ok. Sorry about the noise.
>> Exim does as little work as possible while in a privileged state, and
>> drops privs to do the rest.  To regain privs it execs a new Exim.
> Aha. Not in my setup though. (I see only one Exim process with UID 
> Debian-exim and I see no way that it could re-gain privs, although 
> root-owned, soes not have the suid bit set.)
>> The cert and privatekey files used can depend on information only
>> available immediately before they are needed (such as the remote IP).
>> As such they are only read at that time.
> Aha. Well, that feature is putting some hurdle to the implementation of 
> my idea somehow. 
> How is it activated?

Activated by string expansion. thus it could be the result of a computation
performed externally to exim. (eg: SQL database lookup)

> Actually /all/ those certificates could / would then just need to be 
> read into memory (or a file descriptor to them acquired) early on, i.e. 
> as root. I imagine that it the number of keys is reasonably small for a 
> typical setup - but I have no clue about such setups actually (?).

There's no way to predict the list of possible filenames.

> Or would that already be too much of a security threat in your eyes as 
> well? ... Actually I would argue against it, as with the current setup 
> Exim has access to all key files anyway. ...

One counter (if you only have a few keys) is to build the file contents 
into the exim config file.  Then only those with access to that file can
read the key.

-- 
This email has not been checked by half-arsed antivirus software 

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Reply via email to