[Pkg-exim4-users] Re: pipe aliases and permissions
mh+pkg-exim4-users at zugschlus.de
Sat Dec 10 20:32:02 UTC 2005
On Sat, Dec 10, 2005 at 03:15:13PM -0500, Faheem Mitha wrote:
> On Sat, 10 Dec 2005, Marc Haber wrote:
> >Because it was trying to write as Debian-exim:Debian-exim, as watching
> >a delivery process with -d clearly shows:
> >changed uid/gid: local delivery to |/tmp/mailpipe <|/tmp/mailpipe>
> > uid=105 gid=105 pid=5378
> > auxiliary group list: <none>
> > home=NULL current=/
> What is the best way to turn on debugging?
cat some_message | exim -d target.address at domain.example
> >>Funnily enough, when I set that directory (db) to be writable by anyone,
> >>the owner:group that I saw for the file created by Exim were in fact
> >That is the result of the gid bit on the directory.
> >>Can anyone explain to me what is going on here?
> >See any explanation of UNIX file mode semantics.
> Hmm. the info I can find says things like"the setgid bits causes the
> effective group ID of the process to be set to the group of the file",
> which is unclear. I wonder what they mean by effective group ID?
That's the semantics for _files_. You are looking for the semantics of
the sgid bit on directories. When the sgid bit is set on a directory,
all files created within that directory will have the same group
ownership as the directory itself.
> Does the exim process actually switch group IDs or not?
It should, but it only seems to actually do it when the group is set
on the transport.
> >>Anyway, I'm using the monolithic config file for exim4,
> >>/etc/exim4/exim4.conf.template, and added the following lines at the
> >>beginning to fix this.
> >>SYSTEM_ALIASES_PIPE_TRANSPORT = address_pipe
> >>SYSTEM_ALIASES_USER = Debian-exim
> >>SYSTEM_ALIASES_GROUP = roundup
> >>The section that uses these variables is the exim4-config_system_aliases
> >Setting the group on the transfer seems to work on my system. Now we
> >need to find out why it doesn't work when setting the group on the
> >router. I'm going to ask exim-users about this.
transport. Sorry, a typo.
> Sorry, I don't follow. I thought that I'm setting the user and
> group on the system_aliases router using the SYSTEM_ALIASES_*, which works
> for me.
> What does not work exactly?
Setting the group on the router does not seem to work, it needs to be
set on the transport.
> >>However, my immediate question is whether this will break anything. I have
> >>an /etc/aliases as per usual on Debian, but have not done anything to it
> >>except the Roundup line quoted above.
> >All pipe deliveries are done with group roundup, which I consider
> >unelegant. And it might be a surprise for your successors when they
> >take over the system from you.
> Yes, I didn't think this was the best idea.
It has the advantage of working with all MTAs, which is why program
authors like to take that approach in their docs.
> >>Apparently the Debian Exim maintainers consider pipe transports for
> >>aliases deprecated, and prefer a dedicated router/transport instead.
> >>However, at the moment I've no idea how to do this.
> >Did you take a look at /usr/share/doc/mailman/README.EXIM on a system
> >with mailman installed as suggested in exim's README?
> Yes. That was one of the few things I could find that seemed relevant,
> though I did find similar info for debbugs. I think you had written a
> router/transport pair for that too.
afaik, router/transport pairs exist for debbugs, mailman and
> >The following should be a start:
> > roundup_router:
> > driver = accept
> > require_files = /usr/bin/roundup-mailgw
> > local_parts = newtracker
> > transport = mailman_transport
> Do you mean roundup_transport?
Yes, of course.
> > roundup_transport:
> > driver = pipe
> > command = /usr/bin/python /usr/bin/roundup-mailgw
> > /var/lib/roundup/trackers/newtracker/
> > current_directory =
> > home_directory =
> > user =
> > group =
> Hmm. Perhaps I should have a system user called 'roundup', and have exim
> run as the user/group roundup. Perhaps that would be good?
Depends on what roundup expects. I don't have a clue about roundup, so
I cannot comment about that. I am a big fan of having separate
accounts for different tasks.
> I don't need to set current_directory/home_directory, correct?
> I wonder if one can get Apache to run as a specific user. Probably.
That's quite hard to do. Look for suexec and/or suphp.
> In any case, with your permission, once I get this config a little firmed
> up and make sure it works, I'd like to submit it as a wishlist bug against
> the README.Debian in the Roundup Debian package.
Of course, go ahead.
> (I assume that the config for the split config would be identical, with
> one file for the router subdirectory and one for transport.)
> I'll also possibly suggest to the Roundup maintainers that they make some
> exim-specific comments in their installation guide.
> >This can possibly be gold-plated by having the router or transport
> >look in the roundup config to see wheter a local_part should be
> >handled by roundup.
> Sorry, I'm not sure what you mean. Isn't specifying the local part (which
> seems from context to be the bit before the @), sufficient? What is the
> advantage in having exim look at the roundup config? I'm not even sure how
> this could be done.
I don't know about roundup. the mailman example given above does not
need any exim configuration when new lists are generated: exim looks
in mailman's directory structure whether configuration exists to learn
whether a lists exists or not, and then picks mail addresses belonging
to the mailing list automatically. So, you don't need to touch exim if
you create a new mailman list. If roundup has a concept like a list,
or a queue, that mechanism can be used to avoid exim configuration.
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany | lose things." Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835
More information about the Pkg-exim4-users