Postfix module - Mailman wrapper - Couldn't write data/aliases.db and data/virtual-mailman.db files

[Laurent Declercq]

Dear project leader

At least in version 2.1.23, there is a bug regarding permissions set for Mailman data/aliases table and Mailman data/virtual-mailman map when these files are created from scratch.

Here I describe the current behavior for the Mailman data/aliases table only but the problem is identical for the Mailman data/virtual-mailman map.

In order, the following conditions have to be met:

- Postfix need read access to the aliases.db file
- Mailman like to be owner of those files and the Mailman group needs write access to them

I. Postfix needs a read access to the aliases.db file

We can either set permissions as 0660 and add postfix user to mailman group (what I've done), or set the permissions as 0664

II. Mailman group needs a write access to those files at any time

The following behavior has been observed:

When creating a new list on command line, using bin/newlist script as follow:

    # newlist -u virtualhost foobar

the files will be created as follow:

-rw-rw---- 1 root list aliases
-rw-r----- 1 root list aliases.db

The same thing has been observed when recreating the file from scratch using bin/genaliases:

-rw-rw---- 1 root list aliases
-rw-r----- 1 root list aliases.db

Note that in both cases, files were not present. Thus, they were created from scratch.

As you can see here, the Mailman data/aliases file is created with the expected group and permissions but the data/aliases.db file is only writable by owner. From the POSTALIAS(1) command point of view, that is the expected behavior: The file is created with the same group and other read permissions as their source file.

The problem here is that with those permissions, creating a list through Mailman interface later on will result in a permissions denied error because the Mailman group, through the wrapper, cannot write (update) the aliases.db file (no write permissions).

That is really a problem. Of course, one can just pre-create the files as follow:

# cd /var/lib/mailman
# sg list -c "touch data/aliases && postalias data/aliases"
# chmod 0660 data/aliases*

but that seem tedious. What if at some point (for any reason), the files get recreated from scratch?

So, from my point of view, the MTA/Postfix.py module should always set correct permissions on *.db file, to be sure that Mailman group has write permissions, at least when the files are created from scratch. Eg:

IF NOT EXISTS aliases:
   Touch data/aliases data/aliases.db with correct permissions (066x)
   Add alias entries into aliases as usually
   Run POSTALIAS(1) command as usually

Then, we are fine.

Thank you.

[Mark Sapiro (msapiro)]

There is another issue not mentioned in the original report and that is that aliases.db must be owned by the Mailman user so Postfix runs the pipe as the Mailman user and group.

bin/check_perms would check/fix this and also ensure the mode is at least 0660, but I've gone a step further and now ensure these things at the time the postalias and postmap commands are run and also ensure the mode is at least 0664 so Postfix doesn't need to be in Mailman's group.

[Laurent Declercq (l-declercq)]

@msapiro

I can confirm that the fixes solve the problems.

Thank you for your involvement here. That is much appreciated.

[Christian Ehrhardt  (paelzer)]

Hi,
I see you are updating all bugs upcoming with 2.1.25 - thanks for all your work Mark.
Since on mailman I'm more a triage than anything else I fail to rate the severity of this.
To me it seems that if this would be rather important mailman would never have worked correctly, but it did so I (for now rate it low) and would just pick up the fix on next Merge but not plan for an SRU.
Please if you (much better at estimating mailman usage) think this is SRU worthy please point that out and maybe add a link to the exact fix commit.

[Mark Sapiro (msapiro)]

The fix is http://bazaar.launchpad.net/~mailman-coders/mailman/2.1/revision/1714

I don't think it's a priority. I never saw an issue due to this before this report. Also, in the case of Debian/Ubuntu, if the site takes the postfix_to_mailman.py option (something which I don't recommend - see https://wiki.list.org/x/15564817 - but which the Debian/Ubuntu package seems to encourage), this is not relevant at all.

[Laurent Declercq (l-declercq)]

Le 27/10/2017 à 16:57, Mark Sapiro a écrit :
> The fix is http://bazaar.launchpad.net/~mailman-
> coders/mailman/2.1/revision/1714
>
> I don't think it's a priority. I never saw an issue due to this before
> this report. Also, in the case of Debian/Ubuntu, if the site takes the
> postfix_to_mailman.py option (something which I don't recommend - see
> https://wiki.list.org/x/15564817 - but which the Debian/Ubuntu package
> seems to encourage), this is not relevant at all.
>
We don't make use of that postfix_to_mailman.py script which is really
bad ;)

BTW: We are using mailman on shared hosting where there are huge of
lists. This bug is important to my eyes.

--

Laurent Declercq
iHMS/i-MSCP CEO & Lead Developer

------------------------------------------------------------------------

This message and any attachment are intended solely for the addressees
and are
confidential. iHMS/i-MSCP, including any part representing these
entities may
not be held responsible for their contents whose accuracy and
completeness cannot
be guaranteed over the Internet. Unauthorized use, disclosure,
distribution, copying,
or any part thereof is strictly prohibited. If you are not the intended
recipient of
this message, please notify the sender immediately and delete it.

------------------------------------------------------------------------

[Christian Ehrhardt  (paelzer)]

Ok, I'm not gettign to this soon, but there are also a few steps we have to wait for.
So for now I document the next steps and subscribe the team to look at this again later on:

1. 2.1.25 in Debian
2. 2.1.25 in Ubuntu (Bionic)
3. SRU fix into X-A releases

[Christian Ehrhardt  (paelzer)]

Bionic and Cosmic have 1:2.1.26-1 so #1 and #2 are done.

Given that Mark identified this as:
a) uncommon issue
b) not affecting the usual way the packaging encourages
this isn't a high prio issue, so I'm not sure if it is worth the effort and regression risk to backport it to former releases.

[Christian Ehrhardt  (paelzer)]

I'll be bold and set to Won't Fix to trigger a discussion if people largely disagree.

If this really is an important enough issue for the SRU [1] policy, then I'd ask to help and phrase the SRU template accordingly in a way you are convinced that the SRU Team will accept the regression risk for the benefit this change provides.

[1]: https://wiki.ubuntu.com/StableReleaseUpdates