On Wed, 28 Aug 2002, Rick Byers wrote:
> ... unable to set gid=39 or uid=32767 (euid=8): system_aliases router
> ... temporarily rejected RCPT <...>: internal problem in system_aliases
> router: failure to transfer data from subprocess
Exim is trying to verify an address while receiving an incoming message.
At this stage, it is running as "exim", and so cannot change uid/gid.
You must have a router configuration that requires it to change during
verification - hence the problem.
> I have a pretty standard system_aliases router:
>
> system_aliases:
> driver = redirect
> allow_fail
> allow_defer
> data = ${lookup{$local_part}dbm{/etc/mail/aliases}}
> user = nobody
> file_transport = address_file
> pipe_transport = address_pipe
> The strange thing is that the system_aliases router works fine most of the
> time. Exim will deliver to aliases like:
>
> postmaster: root
> majordomo: "| /usr/pkg/libexec/majordomo/wrapper majordomo"
>
> However, exim fails to deliver (and generates the above error) for
> aliases like
>
> mylist: :include:/home/majordom/lists/mylist
Strictly, it isn't failing to deliver. It is failing to verify the
address during SMTP input.
> So what is different about the way :include: is procecssed from how pipes
> are processed by the redirect router?
:include: is processed at routing time - that is, it has actually to go
and do the work of reading the file at routing time. Pipes are just set
up at routing time; they don't actually happen until delivery.
For security, if a user is supplied (as in your router), Exim runs
:include: as that user. This is typically the case for user's .forward
files. Unfortunately, this causes a problem during verification.
For user's .forward files, you can usually put no_verify to get round
this. In your case, its a bit more complicated. What I suggest is that
you change
user = nobody
file_transport = address_file
pipe_transport = address_pipe
to
file_transport = alias_address_file
pipe_transport = alias_address_pipe
and then provide two new transports as copies of the standard ones, but
with
user = nobody
added to each of them. That way, you aren't supplying a user at routing
time.
The alternative is to supply two different routers, one with no_verify,
and one with verify_only.
> the process accepting SMTP input is running as the exim_user, but is its
> real UID still root (i.e. could it reclaim its root privledges)?.
No. I made a decision that, for Exim 4, there would be no use of
seteuid() at all. Actually, even Exim 3 used setuid() when receiving
SMTP input, so in this part of the code there is no change.
> If not,
> does it just write any message requiring other priveledges to the queue so
> that its picked up by a process with real-uid of root?
Exim *always* writes incoming messages to the queue. In order to do a
delivery, it re-execs itself so as to regain the privilege.
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
