Acknowledgement sent
to Helmut Grohne <[email protected]>:
New Bug report received and forwarded. Copy sent to Mailman for Debian <[email protected]>.
(Wed, 15 Oct 2008 05:51:03 GMT) (full text, mbox, link).
Subject: mailman: policy violation (9.1.1): writes to /usr when config
changes
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:
Acknowledgement sent
to "Thijs Kinkhorst" <[email protected]>:
Extra info received and forwarded to list. Copy sent to Mailman for Debian <[email protected]>.
(Wed, 15 Oct 2008 09:12:05 GMT) (full text, mbox, link).
Subject: Re: [Pkg-mailman-hackers] Bug#502263: mailman: policy violation
(9.1.1): writes to /usr when config changes
Date: Wed, 15 Oct 2008 11:07:05 +0200 (CEST)
On Wed, October 15, 2008 07:48, Helmut Grohne wrote:
> 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).
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
Acknowledgement sent
to Helmut Grohne <[email protected]>:
Extra info received and forwarded to list. Copy sent to Mailman for Debian <[email protected]>.
(Wed, 15 Oct 2008 22:05:04 GMT) (full text, mbox, link).
Subject: Re: [Pkg-mailman-hackers] Bug#502263: mailman: policy violation
(9.1.1): writes to /usr when config changes
Date: Wed, 15 Oct 2008 23:57:46 +0200
> 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.
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.
> 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.
Helmut
Acknowledgement sent
to "Thijs Kinkhorst" <[email protected]>:
Extra info received and forwarded to list. Copy sent to Mailman for Debian <[email protected]>.
(Fri, 17 Oct 2008 21:06:02 GMT) (full text, mbox, link).
Subject: Re: [Pkg-mailman-hackers] Bug#502263: mailman: policy violation
(9.1.1): writes to /usr when config changes
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:
>> 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.
>
> 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.
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
Acknowledgement sent
to Lionel Elie Mamane <[email protected]>:
Extra info received and forwarded to list. Copy sent to Mailman for Debian <[email protected]>.
(Tue, 10 Feb 2009 19:21:03 GMT) (full text, mbox, link).
Subject: Bug#502263: mailman: policy violation (9.1.1): writes to /usr when
config changes
Date: Tue, 10 Feb 2009 20:20:26 +0100
On Wed, Oct 15, 2008 at 11:07:05AM +0200, Thijs Kinkhorst wrote:
> On Wed, October 15, 2008 07:48, Helmut Grohne wrote:
>> (...) /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.
> 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
Acknowledgement sent
to "Thijs Kinkhorst" <[email protected]>:
Extra info received and forwarded to list. Copy sent to Mailman for Debian <[email protected]>.
(Tue, 10 Feb 2009 21:00:05 GMT) (full text, mbox, link).
Subject: Re: Bug#502263: mailman: policy violation (9.1.1): writes to /usr
when config changes
Date: Tue, 10 Feb 2009 21:52:08 +0100 (CET)
On Tue, February 10, 2009 20:20, Lionel Elie Mamane wrote:
> 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).
> As you said in your other message, fixing that in python is even more
> 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
Debbugs is free software and licensed under the terms of the GNU General
Public License version 2. The current version can be obtained
from https://bugs.debian.org/debbugs-source/.