On Thu, 10 May 2001, Marc Mims wrote:
> Actually, I changed the owner.group to majordom.mail. Exim runs
> as mail.mail.
>
> It would appear that even though an alias director is configured
> to run as user majordom, group majordom, with initgroups
> specified, it needs to be able to read the alias file as
> mail.mail. Making mail a member of group majordom does not help.
There is confusion here. Setting user/group/initgoups on an aliasfile
director does NOT configure the director to run as that uid/gid. In Exim
3, directors all run as the Exim user. The user/group/initgroups setting
is used only if the director sets up an explicit delivery (to a file or
pipe in the case of aliasfile) - the settings are then used when the
transport for that delivery runs (much later in the delivery process).
In Exim 4, I have abandoned the use of seteuid() altogether, for
improved overall security. This means that routers (there aren't any
directors in Exim 4) will in fact run as root when delivering mail. A
side-effect of this is that you won't have this kind of problem.
(Routers will still run as exim when verifying during SMTP input.)
Funny how issues suddenly become the issue of the moment. This is the
second time this week that initgroups has arisen. Exim does not
initialize secondary groups when changing to the exim uid/gid. This was
because (a) I didn't think it necessary and (b) on some OS, in some
circumstances, running initgroups() is a very expensive operation. I've
noted a suggestion that (for Exim 4) perhaps there should be an option
to enable initgroups() for the exim uid/gid.
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
