Re: [Exim] problem in system_aliases_router in 4.03

Pàgina inicial
Delete this message
Reply to this message
Autor: Philip Hazel
Data:  
A: Don Hayward
CC: exim-users
Assumptes nous: [Exim] System Filter for 3.2
Assumpte: Re: [Exim] problem in system_aliases_router in 4.03
On Thu, 18 Apr 2002, Don Hayward wrote:

> The routing only trial ran cleanly. So I set up a delivery. The output is
> below with the other requested information. I noticed from the output the
> daemon was running gid = 6 ('mail' on this system) rather than 12 (daemon)
> which is the group of user exim. I also noticed in my system_aliases
> router group is set to daemon. I commented that out and the include
> worked. So things seem ok now. But still puzzling.


I figured this out as I walked home yesterday, but was rehearsing in
the evening, so kept well away from email. :-)

The problem occurs when verifying an address, right?

> daemon running with uid=102 gid=6 euid=102 egid=6


The daemon has started up, abdicated its root privilege, and is running
as uid=102 gid=6 (i.e. "as exim"). This is correct.

> (-- routing the include alias --)


... as the result of an incoming message which does sender or recipient
verification ...

> expanded: :include:/usr/local/exim/lists/testlist
> LOG: MAIN PANIC DIE
> unable to set gid=12 or uid=102 (euid=102): system_aliases router


That is indeed because you have set a different group on the router. Exim
cannot change uid/gid while verifying an address in an SMTP dialogue,
because it is running as exim at that time, not as root. (It's in a
process forked from the daemon.)

Why is it trying to change uid/gid? Because of the presence of :include:
in the value of "data". In this circumstance, the redirect router
creates a subprocess that runs as the user/group specified for the
router, and then opens the :include: file in that process. This is to
ensure that the user/group does have permission to access the file.

If :include: is not present, it does not need to do this. Also, if no
user/group is defined for the router, it likewise does not need to do
this. That is why it works when you comment out the user=daemon setting.

The alert reader might be wondering "What about users' .forward files?
There's no 'user' setting on the userforward router." That's true, but
there is an implicit user setting because "check_local_user" is set.
This means that if a user's .forward contains :include:, the process
that reads it will be running as the user.

--
Philip Hazel            University of Cambridge Computing Service,
ph10@???      Cambridge, England. Phone: +44 1223 334714.