Mailman does not honour MAILMAN_USER on startup

Bug #1917336 reported by Raphael Mankin
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
mailman (Ubuntu)
Invalid
Undecided
Unassigned

Bug Description

I am running mailman as www-data:list rather than as list:list. After a reboot something keeps resetting the ownership /var/run/mailman from www-data:list to list:list. After each reboot I have to reset/restart manually. All other directories & files are fine.

I have hunted all over but I cannot find where this is happening.
This is the tail of /etc/mailman/mm_cfg.py:

#-------------------------------------------------------------
# Uncomment if you want to filter mail with SpamAssassin. For
# more information please visit this website:
# http://www.jamesh.id.au/articles/mailman-spamassassin/
# GLOBAL_PIPELINE.insert(1, 'SpamAssassin')

# Note - if you're looking for something that is imported from mm_cfg, but you
# didn't find it above, it's probably in /usr/lib/mailman/Mailman/Defaults.py.
MAILMAN_USER = 'www-data'

ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: mailman 1:2.1.29-1ubuntu3
ProcVersionSignature: Ubuntu 5.4.0-66.74-generic 5.4.86
Uname: Linux 5.4.0-66-generic x86_64
ApportVersion: 2.20.11-0ubuntu27.16
Architecture: amd64
CasperMD5CheckResult: skip
Date: Mon Mar 1 17:03:44 2021
InstallationDate: Installed on 2021-01-14 (46 days ago)
InstallationMedia: Xubuntu 20.04 LTS "Focal Fossa" - Release amd64 (20200423)
SourcePackage: mailman
UpgradeStatus: No upgrade log present (probably fresh install)

Revision history for this message
Raphael Mankin (raph-p) wrote :
Revision history for this message
Lucas Kanashiro (lucaskanashiro) wrote :

Thank you for taking the time to file a bug report.

Checking the mailman package in Ubuntu Focal I see the logrotate file installed by this package contains some postrotate scripts that might be setting back the ownership to list:list. Take a look at /etc/logrotate.d/mailman and try to make the appropriate changes.

Since it seems likely to me that this is a local configuration problem,
rather than a bug in Ubuntu, I am marking this bug as 'Incomplete'.

However, if you believe that this is really a bug in Ubuntu, then we would
be grateful if you would provide a more complete description of the problem
with steps to reproduce, explain why you believe this is a bug in Ubuntu
rather than a problem specific to your system, and then change the bug
status back to "New".

For local configuration issues, you can find assistance here:
http://www.ubuntu.com/support/community

Changed in mailman (Ubuntu):
status: New → Incomplete
Revision history for this message
Raphael Mankin (raph-p) wrote :

Added log file

Revision history for this message
Sergio Durigan Junior (sergiodj) wrote :

Thanks for the bug report.

This happens because of how systemd handles /var/run/. If you look at the directory, you will see that it is actually a symlink to /run/. This directory is populated on every boot. There are a few ways that packages can choose in order to create directories under this directory; mailman chooses to use a tmpfiles.d configuration file.

If you look at /usr/lib/tmpfiles.d/mailman.conf you will see this:

# path mode uid gid
d /run/mailman 0755 list list
d /run/lock/mailman 2775 root list

In order to achieve what you want, you need to change the "uid" field in the first line. The recommended way to change this file is to actually create a copy of it under /etc/tmpfiles.d/, so that you don't change the original file from the package (which could get overwritten during an update).

To summarize, your file /etc/tmpfiles.d/mailman.conf should look like:

# path mode uid gid
d /run/mailman 0755 www-data list
d /run/lock/mailman 2775 root list

I am closing this bug as Invalid because it is a local configuration question rather than a problem, but please let us know if the steps above don't work for you. Thanks!

Changed in mailman (Ubuntu):
status: Incomplete → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.