Subject: Bug#502263: mailman: policy violation (9.1.1): writes to /usr when config changes

From: Helmut Grohne <[email-masked]>
Date: Wed, 15 Oct 2008 07:48:04 +0200

Package: mailman
Version: 1:2.1.9-7
Severity: serious
Justification: Policy 9.1.1

Policy section 9.1.1 says that FHS must be complied and FHS Chapter 4
says that /usr must not be written to. However after changing the
configuration file /usr/lib/mailman/Mailman/mm_cfg.pyc is updated on
restarting mailman which is a violation of the policy. It should be
non-fatal when /usr is read-only, because python will then simply not
write out the .pyc file. However using tools like tripwire may cause
problems. Please lower the severity of this issue if you think a lower
severity is more appropriate. I only filed it as serious because it
technically is serious (a policy violation).

Helmut

-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-6-686
Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1)

Versions of packages mailman depends on:
ii  adduser                3.102             Add and remove users and groups
ii  apache2                2.2.3-4+etch5     Next generation, scalable, extenda
ii  apache2-mpm-prefork [h 2.2.3-4+etch5     Traditional model for Apache HTTPD
ii  cron                   3.0pl1-100        management of regular background p
ii  debconf [debconf-2.0]  1.5.11etch2       Debian configuration management sy
ii  exim4                  4.63-17           metapackage to ease exim MTA (v4) 
ii  exim4-daemon-light [ma 4.63-17           lightweight exim MTA (v4) daemon
ii  libc6                  2.3.6.ds1-13etch7 GNU C Library: Shared libraries
ii  logrotate              3.7.1-3           Log rotation utility
ii  lsb-base               3.1-23.2etch1     Linux Standard Base 3.1 init scrip
ii  pwgen                  2.05-1            Automatic Password generation
ii  python                 2.4.4-2           An interactive high-level object-o
ii  python-support         0.5.6             automated rebuilding support for p
ii  ucf                    2.0020            Update Configuration File: preserv

mailman recommends no packages.

-- debconf information:
  mailman/queue_files_present:
* mailman/default_server_language: en
  mailman/gate_news: false
* mailman/site_languages: en
* mailman/used_languages:
* mailman/create_site_list:

---

From: "Thijs Kinkhorst" <[email-masked]>
Date: Wed, 15 Oct 2008 11:07:05 +0200 (CEST)

> technically is serious (a policy violation).

Thank you for your report.

I welcome input on this issue from people with more deep knowledge than
myself about these Python cached files, and how we could best address it
in this case. If there's a straightforward solution I think we can apply
it for lenny.

However I indeed don't think this should be release critical, as you say,
it doesn't break when writing fails. It is an inconvenience with e.g.
tripwire, but that is resolvable within the context of that application.
So I would classify it as an 'important' issue myself.

cheers,
Thijs

---

From: Helmut Grohne <[email-masked]>
Date: Wed, 15 Oct 2008 23:57:46 +0200

> in this case. If there's a straightforward solution I think we can apply

The simplest solution might actually be to take the approach
python-support uses.

1) The .py files stay where they are.
2) They are symlinked to a directory hierarchy within /var/lib. (This
   means directories are copied and files are symlinked.)
3) The .pyc files will get created on /var.
4) The module path has to be adapted from /usr/lib/mailman to something
   on /var. Therefore /usr/lib/mailman/bin/paths.py should be adapted.

> So I would classify it as an 'important' issue myself.

ACK.

Helmut

---

From: "Thijs Kinkhorst" <[email-masked]>
Date: Fri, 17 Oct 2008 23:05:01 +0200 (CEST)

severity 502263 important
thanks

Hi Helmut,

On Wed, October 15, 2008 23:57, Helmut Grohne wrote:
>>  myself about these Python cached files, and how we could best address
>> it in this case. If there's a straightforward solution I think we can
>> apply it for lenny.
>

Right. I'm afraid that I don't think this juggling with symlinks and
changing the module path at the verge of Lenny's release is a wise thing
to do.

Would this really solve the root cause? It seems quite an extensive
workaround for the problem that Python saves caching data right next to
the original data. Wouldn't it be better configure Python to save that
under /var/cache, than to implement magic in every application?

>> However I indeed don't think this should be release critical, as you
>> say, it doesn't break when writing fails. It is an inconvenience with
>> e.g. tripwire, but that is resolvable within the context of that
>> application. So I would classify it as an 'important' issue myself.
>>
>
> ACK.

Downgrading the severity.

Thijs

---

From: Lionel Elie Mamane <[email-masked]>
Date: Tue, 10 Feb 2009 20:20:26 +0100

>> (...) /usr must not be written to. However after changing the
>> restarting mailman which is a violation of the policy.

> I welcome input on this issue from people with more deep knowledge
> than myself about these Python cached files, and how we could best
> address it in this case. If there's a straightforward solution I
> think we can apply it for lenny.

Too late for lenny now, but it would be worth testing if installing a
dangling symlink
   /usr/lib/mailman/Mailman/mm_cfg.pyc -> /var/cache/mailman/mm_cfg.pyc
in the package would lead to python create and update the file there
(as opposed to remove the symlink and create the file there).

preinst magic may be needed, dpkg might refuse to overwrite the
already existing (unregistered / unknown) file with a symlink,
although I don't think it will. (Just unconditionally removing the
file may do the trick.)

As you said in your other message, fixing that in python is even more
groovy, but that would lead to interesting problems of when / how to
purge the cache, how to handle (store the (device,inode) number in the
pyc file and compare if it has changed?) different mounts leading to
different files being at the same path (name) at different points of
time, ... A very cool solution (but not applicable at the package
level with the Linux kernel) is make /usr/lib/mailman/Mailman an
unionfs that writes any non-package originated file to
/var/cache/mailman/Mailman/ :)

-- 
Lionel

---

From: "Thijs Kinkhorst" <[email-masked]>
Date: Tue, 10 Feb 2009 21:52:08 +0100 (CET)

On Tue, February 10, 2009 20:20, Lionel Elie Mamane wrote:
> dangling symlink /usr/lib/mailman/Mailman/mm_cfg.pyc ->
> /var/cache/mailman/mm_cfg.pyc
> in the package would lead to python create and update the file there (as
> opposed to remove the symlink and create the file there).

> groovy,

This, perhaps a bit dated, message from the Python team suggests that not
creating .pyc files at all may be an avenue to pursue:
http://lists.debian.org/debian-python/2005/12/msg00016.html

Thijs