Bug#292191: upgrade changes ownerhsip of /var/spool/exim4

[Marc Haber]

On Tue, Jan 25, 2005 at 08:38:55PM +0100,  Marc A. Lehmann  wrote:
> On Tue, Jan 25, 2005 at 07:42:20PM +0100, Marc Haber <mh+debian-packages@zugschlus.de> wrote:
> > On Tue, Jan 25, 2005 at 05:30:53PM +0100, Marc Lehmann wrote:
> > > Package: exim4
> > > Version: 4.43-4
> > > Severity: critical
> > > Justification: causes serious data loss
> > 
> > NACK
> 
> Reason? It's not your mail that has been lost, and the bug certainly
> causes non-restorable data loss.

I does not. Any sensible sender will queue for multiple days.

> > > I tagged this report as critical because the problem has caused mail to be
> > > lost in the past and would likely result in lost mail in the future.
> > 
> > side. Since you surely won't update a productive system without
> > monitoring your logs after the upgrade
> 
> Thanks that you know what we do. Unfortunately, logs didn't show anything
> bad as exim4 started fine and the system didn't receive mail for some
> time.

And you didn't think of testing your setup after upgrading your
non-released development version of your Linux distribution?

> > worst thing that's going to
> > happen is that you won't accept new messages for an hour and having
> > them re-delivered by the remote side some time later.
> 
> This has not happened, presumably because within the 24 hours that this
> happened, the other mail already stopped retrying.

The other mailes are broken.

> If you think that losing mails is not serious data loss, speak up please.

A mailer being down for less than 48 hours should not cause data loss.

> Otherwise please acknowledge that this bug causes the problem to happen.

I already did that.

> > Would it be OK for you to manually add a mode override (using
> > dpkg-statoverride) and have future versions of the exim4 packages
> > refrain from chowning the files if a manual override can be detected?
> 
> For me, yes, but for others probably not. This is a bug and it should be
> fixed properly.

Please outline a possible fix that will allow upgrades from exim4
4.24-3 to a current version (both of them using a debconf-generated
config without local changes) to function properly.

> If users cannot edit the exim4 confgi file then it must go
> out of /etc.

People can edit the exim4 config file. But they might be required to
touch other parts of the system, for example telling the system that
they explicitly want non-default file modes.

It is a bug that the exim4 packages currently do not have that
possibility. They will have an interface to dpkg-statoverride in due
time.

Greetings
Marc

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things."    Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 621 72739835