Mailman GID problem

[Jeffrey Goldberg]

On Apr 20, 2007, at 4:31 PM, Paul Schmehl wrote:

> --On Friday, April 20, 2007 14:23:14 -0500 Jeffrey Goldberg  
> <jeffrey at goldmark.org> wrote:
>
>> Can you tell me where to find the unprocessed version of pkg-install?
>> What is in work/ has already been processed by sed, and I didn't see
>> anything obvious in files/

> /usr/ports/mail/mailman/pkg-install

Ah.  It was right under my nose.

>> I'm beginning to think that the fix will be as simple as
>>
>> --- Makefile.orig       Fri Apr 20 14:17:08 2007
>> +++ Makefile    Fri Apr 20 14:18:14 2007
>> @@ -88,7 +88,7 @@
>> .if defined(WITH_SENDMAIL) || defined(WITH_EXIM3) || defined 
>> (WITH_EXIM4)
>> BROKEN=        choose only one MTA integration
>> .endif
>> -MAIL_GID?=     nobody
>> +MAIL_GID?=     mailman
>> .endif
>> .if defined(WITH_CHINESE)
>>
> No, that's *absolutely* the wrong fix.  The group required for  
> mailman to work depends on the mail server you are using.   
> Sendmail, postfix, qmail, etc. all require different groups.  So  
> using a fixed group might work for you, but it would break it for a  
> lot of other people's setups.

I think I'm beginning to understand where that "nobody" comes from  
and why you are right about that.

Here is an excerpt from the postfix aliases(5)

   In the absence of a user context,  the  local(8)  daemon  uses   
the  owner
   rights  of  the :include: file or alias database.  When those  
files are
   owned by the superuser, delivery is made with the rights specified  
with
   the default_privs configuration parameter.

I had been looking at the first half of that (which I was already  
aware of).  So I thought that if the wrapper were compiled to only  
run as "nobody" than the relevant alias files had to be owned by  
"nobody".  I wasn't, until looking this up, aware of what happens  
when the aliases file is owned by root.

In the postfix out of ports on FreeBSD, default_privs is set to  
"nobody".

So the first fix (modifying the owner of data/aliases{,.db}) is the  
right way to go, but instead of making those files owned by  
"nobody" (which does seem dangerous because than anything running as  
"nobody" could change those file) they should be owned by root with  
mailman as the group and permissions like 664.

Let me just test that now... Yes.  Mail delivery seems to work with

[jeffrey at dobby /usr/local/mailman/data]$ ls -la .
total 78
drwxrwsr-x   2 root     mailman   1024 Apr 19 16:03 .
drwxrwsr-x  20 mailman  mailman    512 Mar 30 13:57 ..
-rw-r-----   1 root     mailman     41 Sep 11  2006 adm.pw
-rw-rw----   1 root     mailman   3523 Mar 31 16:10 aliases
-rw-rw-r--   1 root     mailman  16384 Mar 31 16:10 aliases.db
-rw-rw-r--   1 root     mailman  12288 Sep 13  2006 aliases.db.rpmsave
-rw-r-----   1 root     mailman     41 Sep 11  2006 creator.pw
-rw-r--r--   1 root     mailman     10 Mar 30 13:57 last_mailman_version
-rw-rw----   1 root     mailman      4 Apr 17 14:34 master-qrunner.pid
-rw-r--r--   1 root     mailman  14114 Mar 30 13:57 sitelist.cfg
-rw-rw----   1 root     mailman   3334 Mar 31 16:10 virtual-mailman
-rw-rw-r--   1 root     mailman  16384 Mar 31 16:10 virtual-mailman.db

I haven't yet tested list creation, but the permissions look fine to  
me.  All of the relevant files (as well as the data directory itself)  
are writable by members of the mailman group.

But I think I now see the problem

$ ../bin/check_perms
/usr/local/mailman/data/aliases.db owned by root (must be owned by  
mailman
/usr/local/mailman/data/virtual-mailman.db owned by root (must be  
owned by mailman
Problems found: 2
Re-run as mailman (or root) with -f flag to fix

Somehow check_perms doesn't seem to know how postfix does things.  If  
I were to actually run

   check_perms -f

it would break to ownership of the aliases file so that we would have  
the mismatch between what the uid postfix gives the the wrapper  
("mailman") and what the wrapper demands ("nobody").

So maybe the problem is with check_perms and not with the port at all  
(well the port would still need to get the aliases files owned by root).

While setting the aliases files to be owned by "nobody" or by making  
the wrapper want "mailman" instead of "nobody" would be work-arounds,  
both of those lose out on the security achieved by having the aliases  
files owned by root.

Of course my two previous "understandings" of how things were  
supposed to work were wrong.  So please take my current analysis with  
a large grain of salt.

And thank you all for your patience in putting up with my half-baked  
postings.

Cheers,

-j

-- 
Jeffrey Goldberg                        http://www.goldmark.org/jeff/