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

[Faheem Mitha]

On Sat, 10 Dec 2005, Marc Haber wrote:

> On Sat, Dec 10, 2005 at 03:15:13PM -0500, Faheem Mitha wrote:

>> On Sat, 10 Dec 2005, Marc Haber wrote:

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

No, my question was referring to the situation when there is no 
router/transport, the default behavior where there is a permission 
problem.

For example, if just

SYSTEM_ALIASES_PIPE_TRANSPORT = address_pipe

was set.

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

It works for me with the system_aliases router that exists in the 
/etc/exim4/exim4.conf.template, as I have already said.

I think you are talking about the custom roundup_router & 
coundup_transport that you wrote. Is my understanding correct?

> afaik, router/transport pairs exist for debbugs, mailman and
> request-tracker.

I'm not aware of one for RT, and I just looked at the docs for the Debian 
unstable package the other day.

>> 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 think that roundup is fussy about how permissions are set up in 
the db directory in the tracker instance. It just needs the MTA process 
and the web server process to be able to write to it.

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

Thanks for the tip.

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

Ah, I see. Yes, roundup has a tracker instance, which is what newtracker 
is in my example.

Eg. each directory in /var/lib/roundup/trackers belongs to a tracker 
instance.

I think it would suffice to configure an mail address (or whatever it is 
called) corresponding to each local instance.

So if there were directories /var/lib/roundup/trackers/track1 and 
/var/lib/roundup/trackers/track2, then configure mail addresses track1 and 
track2. Presumably one should do this in the router.

I see that the mailman router/transport for Exim 4 is

******************************************************************
   mailman_router:
     driver = accept
     require_files = MAILMAN_HOME/lists/$local_part/config.pck
     local_part_suffix_optional
     local_part_suffix = -bounces : -bounces+* : \
                         -confirm+* : -join : -leave : \
                         -owner : -request : -admin
     transport = mailman_transport

  mailman_transport:
     driver = pipe
     command = MAILMAN_WRAP \
               '${if def:local_part_suffix \
                     {${sg{$local_part_suffix}{-(\\w+)(\\+.*)?}{\$1}}} \
                     {post}}' \
               $local_part
     current_directory = MAILMAN_HOME
     home_directory = MAILMAN_HOME
     user = MAILMAN_USER
     group = MAILMAN_GROUP
******************************************************************

Would something like the following work for Roundup? It looks like 
$local_part is extracted by matching require_files, correct?

******************************************************************
   # Home dir for your Roundup installation
   ROUNDUP_HOME=/var/lib/roundup/trackers

   # User and group for Roundup.
   ROUNDUP_USER=roundup
   ROUNDUP_GROUP=roundup

   roundup_router:
     driver = accept
     # The config file config.ini seems like a more natural choice, but the
     # file config.py was replaced by config.ini in 0.8, and schema.py needs to be
     # present too.
     require_files = /usr/bin/roundup-mailgw, ROUNDUP_HOME/$local_part/schema.py
     transport = roundup_transport

   roundup_transport:
     driver = pipe
     command = /usr/bin/python /usr/bin/roundup-mailgw ROUNDUP_HOME/$local_part/
     current_directory =
     home_directory =
     user = ROUNDUP_USER
     group = ROUNDUP_GROUP
***************************************************************

Thanks.                                                          Faheem.