[Pkg-exim4-users] Re: pipe aliases and permissions

[Faheem Mitha]

Hi Marc,

Thanks for the super helpful reply, and sorry for being so clueless.

On Sat, 10 Dec 2005, Marc Haber wrote:

> On Fri, Dec 09, 2005 at 03:21:51PM -0500, Faheem Mitha wrote:

>> I did a search in gmane for exim mailing lists. It was a nice surprise to
>> find a Debian-specific one.
>
> It is also prominently mentioned in the Debian package.

Easy to miss the obvious, sorry.

>> However, surely it must be running under some default permissions in that
>> case? What are those?
>
> It runs as the user Debian-exim, which has write access to the mail
> logs, and to the mail spool. I hope that it is clear that running user
> processes with these set of privileges is almost as bad an idea as
> root is.

True.

> Exim does not assume the privileges of any additional groups that the
> Exim user might be in for local deliveries. This is discussed in
> spec.txt, chapter 23. But that's irrelevant here since you set a group
> on the router.

Ah, I see. Not really irrelevant, because I only set the group after 
running into this problem.

>> So, if exim was to write to the directory with owner:group
>> Debian-exim:roundup, it would be Ok, but i was getting permission errors.
>
> 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> transport=address_pipe
>  uid=105 gid=105 pid=5378
>  auxiliary group list: <none>
>  home=NULL current=/

What is the best way to turn on debugging?

>> 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
>> Debian-exim:roundup.
>
> 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?

Does the exim process actually switch group IDs or not?

If it does not, then the exim process is still running as 
Debian-exim:Debian-exim. So does this mean that the permissions of the 
file written to the disk is not actually what the process was running as?

If it does, then why does it not have permission to write to the 
directory?

>> 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
>> section.
>
> 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.

'transfer'? 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?

>> 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.

>> 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.

However, I couldn't understand what needed to be done well enough to do it 
for Roundup.

> 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?

>  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?

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.

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.

(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.

>> BTW, has anyone read The Exim SMTP Mail Server Official Guide for Release
>> 4 (http://www.uit.co.uk/exim-book/)? If so, what did you think of it?
>
> It is an excellent book, straight from "the horses mouth", and much
> better as a tutorial as the spec.txt file which is more a reference
> than a tutorial.

Thanks. I'll try to get hold of a copy.

                                                               Faheem.