[users] update mimedefang.i386 2.68-1.el5.rf killed mail service

[Tilman Schmidt]

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA1



On March 22, two of my mail servers running CentOS 5.4 with Sendmail,
MIMEDefang and ClamAV stopped passing mail, filling their logs with
error messages like this:

Mar 22 14:49:47 gimli sendmail[7855]: o2MDnlWB007855: Milter
(mimedefang): local socket name /var/spool/MIMEDefang/mimedefang.sock unsafe
Mar 22 14:49:47 gimli sendmail[7855]: o2MDnlWB007855: Milter
(mimedefang): to error state

This happened immediately after the yum.log entry:

Mar 22 14:03:10 Updated: mimedefang.i386 2.68-1.el5.rf

MIMEDefang was stopped and could not be started, complaining:

Starting mimedefang-multiplexor: /usr/bin/mimedefang-multiplexor: Unable
to chdir(/var/spool/MIMEDefang): Permission denied
[FAILED]
Starting mimedefang: /usr/bin/mimedefang: Unable to
chdir(/var/spool/MIMEDefang): Permission denied
[FAILED]

It turned out the owner of the directories
/var/spool/MIMEDefang
/var/spool/MD-Quarantine
had been changed from "clamav" to "defang", killing MIMEDefang.
I can only assume that the update did this, as "defang" is the
original owner of those directories in that package.

Background: the rpmforge packages clamd and mimedefang do not
cooperate out of the box, because they run as different users
and clamd cannot read the files that MIMEDefang asks it to scan.
To fix this I changed MIMEDefang's configuration to run as the
clamav user, and adapted the ownership of its spool and log
directories accordingly. This has worked quite well until that
fateful mimedefang update.

Any suggestions for avoiding that kind of incident in the future?

Thanks,
Tilman

- --
Tilman Schmidt
Phoenix Software GmbH
Bonn, Germany

[Yury V. Zaytsev]

Post by Tilman Schmidt
I can only assume that the update did this, as "defang" is the
original owner of those directories in that package.

The package itself has not been changed... It just resets the ownership
to the defaults.

Post by Tilman Schmidt
Any suggestions for avoiding that kind of incident in the future?

Add clamav to defang's group?

[Tilman Schmidt]

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA1

Post by Yury V. Zaytsev

Post by Tilman Schmidt
I can only assume that the update did this, as "defang" is the
original owner of those directories in that package.

The package itself has not been changed... It just resets the ownership
to the defaults.

Yes, that's the problem.

Post by Yury V. Zaytsev

Post by Tilman Schmidt
Any suggestions for avoiding that kind of incident in the future?

Add clamav to defang's group?

That doesn't help. The MIMEDefang spool directory has mode 700,
ie. no group access.

Thanks,
Tilman

- --
Tilman Schmidt
Phoenix Software GmbH
Bonn, Germany

[Yury V. Zaytsev]

Post by Tilman Schmidt

Post by Yury V. Zaytsev

Post by Tilman Schmidt
Any suggestions for avoiding that kind of incident in the future?

Add clamav to defang's group?

That doesn't help. The MIMEDefang spool directory has mode 700,
ie. no group access.

Maybe we shall change it to 0750? What do you guys think?

[Tilman Schmidt]

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA1

Post by Yury V. Zaytsev

Post by Tilman Schmidt

Post by Yury V. Zaytsev

Post by Tilman Schmidt
Any suggestions for avoiding that kind of incident in the future?

Add clamav to defang's group?

That doesn't help. The MIMEDefang spool directory has mode 700,
ie. no group access.

Maybe we shall change it to 0750? What do you guys think?

That would be good. It looks like it would solve my problem, and
I cannot see any negative consequences.

Perhaps the mimedefang and/or clamav packages could even be taught
to add their users to each other's groups? (I don't know whether
rpm can do that kind of thing.)

Thanks,
Tilman

- --
Tilman Schmidt
Phoenix Software GmbH
53227 Bonn, Germany

[Tilman Schmidt]

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA1

Post by Yury V. Zaytsev

Post by Tilman Schmidt

Post by Yury V. Zaytsev

Post by Tilman Schmidt
Any suggestions for avoiding that kind of incident in the future?

Add clamav to defang's group?

That doesn't help. The MIMEDefang spool directory has mode 700,
ie. no group access.

Maybe we shall change it to 0750? What do you guys think?

That would be good. It looks like it would solve my problem, and
I cannot see any negative consequences.

Perhaps the mimedefang and/or clamav packages could even be taught
to add their users to each other's groups? (I don't know whether
rpm can do that kind of thing.)

Thanks,
Tilman

- --
Tilman Schmidt
Phoenix Software GmbH
53227 Bonn, Germany

[Tilman Schmidt]

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA1

Post by Yury V. Zaytsev

Post by Tilman Schmidt

Post by Yury V. Zaytsev

Post by Tilman Schmidt
Any suggestions for avoiding that kind of incident in the future?

Add clamav to defang's group?

That doesn't help. The MIMEDefang spool directory has mode 700,
ie. no group access.

Maybe we shall change it to 0750? What do you guys think?

That would be good. It looks like it would solve my problem, and
I cannot see any negative consequences.

Perhaps the mimedefang and/or clamav packages could even be taught
to add their users to each other's groups? (I don't know whether
rpm can do that kind of thing.)

Thanks,
Tilman

- --
Tilman Schmidt
Phoenix Software GmbH
53227 Bonn, Germany

[Tilman Schmidt]

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA1

Post by Yury V. Zaytsev

Post by Tilman Schmidt

Post by Yury V. Zaytsev

Post by Tilman Schmidt
Any suggestions for avoiding that kind of incident in the future?

Add clamav to defang's group?

That doesn't help. The MIMEDefang spool directory has mode 700,
ie. no group access.

Maybe we shall change it to 0750? What do you guys think?

That would be good. It looks like it would solve my problem, and
I cannot see any negative consequences.

Perhaps the mimedefang and/or clamav packages could even be taught
to add their users to each other's groups? (I don't know whether
rpm can do that kind of thing.)

Thanks,
Tilman

- --
Tilman Schmidt
Phoenix Software GmbH
53227 Bonn, Germany

[Tilman Schmidt]

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA1

Post by Yury V. Zaytsev

Post by Tilman Schmidt

Post by Yury V. Zaytsev

Post by Tilman Schmidt
Any suggestions for avoiding that kind of incident in the future?

Add clamav to defang's group?

That doesn't help. The MIMEDefang spool directory has mode 700,
ie. no group access.

Maybe we shall change it to 0750? What do you guys think?

That would be good. It looks like it would solve my problem, and
I cannot see any negative consequences.

Perhaps the mimedefang and/or clamav packages could even be taught
to add their users to each other's groups? (I don't know whether
rpm can do that kind of thing.)

Thanks,
Tilman

- --
Tilman Schmidt
Phoenix Software GmbH
53227 Bonn, Germany

[Yury V. Zaytsev]

Post by Tilman Schmidt

Post by Yury V. Zaytsev

Post by Tilman Schmidt
Any suggestions for avoiding that kind of incident in the future?

Add clamav to defang's group?

That doesn't help. The MIMEDefang spool directory has mode 700,
ie. no group access.

Maybe we shall change it to 0750? What do you guys think?

[Yury V. Zaytsev]

Post by Tilman Schmidt

Post by Yury V. Zaytsev

Post by Tilman Schmidt
Any suggestions for avoiding that kind of incident in the future?

Add clamav to defang's group?

That doesn't help. The MIMEDefang spool directory has mode 700,
ie. no group access.

Maybe we shall change it to 0750? What do you guys think?

[Yury V. Zaytsev]

Post by Tilman Schmidt

Post by Yury V. Zaytsev

Post by Tilman Schmidt
Any suggestions for avoiding that kind of incident in the future?

Add clamav to defang's group?

That doesn't help. The MIMEDefang spool directory has mode 700,
ie. no group access.

Maybe we shall change it to 0750? What do you guys think?

[Yury V. Zaytsev]

Post by Tilman Schmidt

Post by Yury V. Zaytsev

Post by Tilman Schmidt
Any suggestions for avoiding that kind of incident in the future?

Add clamav to defang's group?

That doesn't help. The MIMEDefang spool directory has mode 700,
ie. no group access.

Maybe we shall change it to 0750? What do you guys think?

[Tilman Schmidt]

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA1

Post by Yury V. Zaytsev

Post by Tilman Schmidt
I can only assume that the update did this, as "defang" is the
original owner of those directories in that package.

The package itself has not been changed... It just resets the ownership
to the defaults.

Yes, that's the problem.

Post by Yury V. Zaytsev

Post by Tilman Schmidt
Any suggestions for avoiding that kind of incident in the future?

Add clamav to defang's group?

That doesn't help. The MIMEDefang spool directory has mode 700,
ie. no group access.

Thanks,
Tilman

- --
Tilman Schmidt
Phoenix Software GmbH
Bonn, Germany

[Tilman Schmidt]

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA1

Post by Yury V. Zaytsev

Post by Tilman Schmidt
I can only assume that the update did this, as "defang" is the
original owner of those directories in that package.

The package itself has not been changed... It just resets the ownership
to the defaults.

Yes, that's the problem.

Post by Yury V. Zaytsev

Post by Tilman Schmidt
Any suggestions for avoiding that kind of incident in the future?

Add clamav to defang's group?

That doesn't help. The MIMEDefang spool directory has mode 700,
ie. no group access.

Thanks,
Tilman

- --
Tilman Schmidt
Phoenix Software GmbH
Bonn, Germany

[Tilman Schmidt]

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA1

Post by Yury V. Zaytsev

Post by Tilman Schmidt
I can only assume that the update did this, as "defang" is the
original owner of those directories in that package.

The package itself has not been changed... It just resets the ownership
to the defaults.

Yes, that's the problem.

Post by Yury V. Zaytsev

Post by Tilman Schmidt
Any suggestions for avoiding that kind of incident in the future?

Add clamav to defang's group?

That doesn't help. The MIMEDefang spool directory has mode 700,
ie. no group access.

Thanks,
Tilman

- --
Tilman Schmidt
Phoenix Software GmbH
Bonn, Germany

[Tilman Schmidt]

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA1

Post by Yury V. Zaytsev

Post by Tilman Schmidt
I can only assume that the update did this, as "defang" is the
original owner of those directories in that package.

The package itself has not been changed... It just resets the ownership
to the defaults.

Yes, that's the problem.

Post by Yury V. Zaytsev

Post by Tilman Schmidt
Any suggestions for avoiding that kind of incident in the future?

Add clamav to defang's group?

That doesn't help. The MIMEDefang spool directory has mode 700,
ie. no group access.

Thanks,
Tilman

- --
Tilman Schmidt
Phoenix Software GmbH
Bonn, Germany

[Tilman Schmidt]

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA1



On March 22, two of my mail servers running CentOS 5.4 with Sendmail,
MIMEDefang and ClamAV stopped passing mail, filling their logs with
error messages like this:

Mar 22 14:49:47 gimli sendmail[7855]: o2MDnlWB007855: Milter
(mimedefang): local socket name /var/spool/MIMEDefang/mimedefang.sock unsafe
Mar 22 14:49:47 gimli sendmail[7855]: o2MDnlWB007855: Milter
(mimedefang): to error state

This happened immediately after the yum.log entry:

Mar 22 14:03:10 Updated: mimedefang.i386 2.68-1.el5.rf

MIMEDefang was stopped and could not be started, complaining:

Starting mimedefang-multiplexor: /usr/bin/mimedefang-multiplexor: Unable
to chdir(/var/spool/MIMEDefang): Permission denied
[FAILED]
Starting mimedefang: /usr/bin/mimedefang: Unable to
chdir(/var/spool/MIMEDefang): Permission denied
[FAILED]

It turned out the owner of the directories
/var/spool/MIMEDefang
/var/spool/MD-Quarantine
had been changed from "clamav" to "defang", killing MIMEDefang.
I can only assume that the update did this, as "defang" is the
original owner of those directories in that package.

Background: the rpmforge packages clamd and mimedefang do not
cooperate out of the box, because they run as different users
and clamd cannot read the files that MIMEDefang asks it to scan.
To fix this I changed MIMEDefang's configuration to run as the
clamav user, and adapted the ownership of its spool and log
directories accordingly. This has worked quite well until that
fateful mimedefang update.

Any suggestions for avoiding that kind of incident in the future?

Thanks,
Tilman

- --
Tilman Schmidt
Phoenix Software GmbH
Bonn, Germany

[Yury V. Zaytsev]

Post by Tilman Schmidt
I can only assume that the update did this, as "defang" is the
original owner of those directories in that package.

The package itself has not been changed... It just resets the ownership
to the defaults.

Post by Tilman Schmidt
Any suggestions for avoiding that kind of incident in the future?

Add clamav to defang's group?

[Tilman Schmidt]

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA1



On March 22, two of my mail servers running CentOS 5.4 with Sendmail,
MIMEDefang and ClamAV stopped passing mail, filling their logs with
error messages like this:

Mar 22 14:49:47 gimli sendmail[7855]: o2MDnlWB007855: Milter
(mimedefang): local socket name /var/spool/MIMEDefang/mimedefang.sock unsafe
Mar 22 14:49:47 gimli sendmail[7855]: o2MDnlWB007855: Milter
(mimedefang): to error state

This happened immediately after the yum.log entry:

Mar 22 14:03:10 Updated: mimedefang.i386 2.68-1.el5.rf

MIMEDefang was stopped and could not be started, complaining:

Starting mimedefang-multiplexor: /usr/bin/mimedefang-multiplexor: Unable
to chdir(/var/spool/MIMEDefang): Permission denied
[FAILED]
Starting mimedefang: /usr/bin/mimedefang: Unable to
chdir(/var/spool/MIMEDefang): Permission denied
[FAILED]

It turned out the owner of the directories
/var/spool/MIMEDefang
/var/spool/MD-Quarantine
had been changed from "clamav" to "defang", killing MIMEDefang.
I can only assume that the update did this, as "defang" is the
original owner of those directories in that package.

Background: the rpmforge packages clamd and mimedefang do not
cooperate out of the box, because they run as different users
and clamd cannot read the files that MIMEDefang asks it to scan.
To fix this I changed MIMEDefang's configuration to run as the
clamav user, and adapted the ownership of its spool and log
directories accordingly. This has worked quite well until that
fateful mimedefang update.

Any suggestions for avoiding that kind of incident in the future?

Thanks,
Tilman

- --
Tilman Schmidt
Phoenix Software GmbH
Bonn, Germany

[Yury V. Zaytsev]

Post by Tilman Schmidt
I can only assume that the update did this, as "defang" is the
original owner of those directories in that package.

The package itself has not been changed... It just resets the ownership
to the defaults.

Post by Tilman Schmidt
Any suggestions for avoiding that kind of incident in the future?

Add clamav to defang's group?

[Tilman Schmidt]

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA1



On March 22, two of my mail servers running CentOS 5.4 with Sendmail,
MIMEDefang and ClamAV stopped passing mail, filling their logs with
error messages like this:

Mar 22 14:49:47 gimli sendmail[7855]: o2MDnlWB007855: Milter
(mimedefang): local socket name /var/spool/MIMEDefang/mimedefang.sock unsafe
Mar 22 14:49:47 gimli sendmail[7855]: o2MDnlWB007855: Milter
(mimedefang): to error state

This happened immediately after the yum.log entry:

Mar 22 14:03:10 Updated: mimedefang.i386 2.68-1.el5.rf

MIMEDefang was stopped and could not be started, complaining:

Starting mimedefang-multiplexor: /usr/bin/mimedefang-multiplexor: Unable
to chdir(/var/spool/MIMEDefang): Permission denied
[FAILED]
Starting mimedefang: /usr/bin/mimedefang: Unable to
chdir(/var/spool/MIMEDefang): Permission denied
[FAILED]

It turned out the owner of the directories
/var/spool/MIMEDefang
/var/spool/MD-Quarantine
had been changed from "clamav" to "defang", killing MIMEDefang.
I can only assume that the update did this, as "defang" is the
original owner of those directories in that package.

Background: the rpmforge packages clamd and mimedefang do not
cooperate out of the box, because they run as different users
and clamd cannot read the files that MIMEDefang asks it to scan.
To fix this I changed MIMEDefang's configuration to run as the
clamav user, and adapted the ownership of its spool and log
directories accordingly. This has worked quite well until that
fateful mimedefang update.

Any suggestions for avoiding that kind of incident in the future?

Thanks,
Tilman

- --
Tilman Schmidt
Phoenix Software GmbH
Bonn, Germany

[Yury V. Zaytsev]

Post by Tilman Schmidt
I can only assume that the update did this, as "defang" is the
original owner of those directories in that package.

The package itself has not been changed... It just resets the ownership
to the defaults.

Post by Tilman Schmidt
Any suggestions for avoiding that kind of incident in the future?

Add clamav to defang's group?

[Tilman Schmidt]

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA1



On March 22, two of my mail servers running CentOS 5.4 with Sendmail,
MIMEDefang and ClamAV stopped passing mail, filling their logs with
error messages like this:

Mar 22 14:49:47 gimli sendmail[7855]: o2MDnlWB007855: Milter
(mimedefang): local socket name /var/spool/MIMEDefang/mimedefang.sock unsafe
Mar 22 14:49:47 gimli sendmail[7855]: o2MDnlWB007855: Milter
(mimedefang): to error state

This happened immediately after the yum.log entry:

Mar 22 14:03:10 Updated: mimedefang.i386 2.68-1.el5.rf

MIMEDefang was stopped and could not be started, complaining:

Starting mimedefang-multiplexor: /usr/bin/mimedefang-multiplexor: Unable
to chdir(/var/spool/MIMEDefang): Permission denied
[FAILED]
Starting mimedefang: /usr/bin/mimedefang: Unable to
chdir(/var/spool/MIMEDefang): Permission denied
[FAILED]

It turned out the owner of the directories
/var/spool/MIMEDefang
/var/spool/MD-Quarantine
had been changed from "clamav" to "defang", killing MIMEDefang.
I can only assume that the update did this, as "defang" is the
original owner of those directories in that package.

Background: the rpmforge packages clamd and mimedefang do not
cooperate out of the box, because they run as different users
and clamd cannot read the files that MIMEDefang asks it to scan.
To fix this I changed MIMEDefang's configuration to run as the
clamav user, and adapted the ownership of its spool and log
directories accordingly. This has worked quite well until that
fateful mimedefang update.

Any suggestions for avoiding that kind of incident in the future?

Thanks,
Tilman

- --
Tilman Schmidt
Phoenix Software GmbH
Bonn, Germany

[Yury V. Zaytsev]

Post by Tilman Schmidt
I can only assume that the update did this, as "defang" is the
original owner of those directories in that package.

The package itself has not been changed... It just resets the ownership
to the defaults.

Post by Tilman Schmidt
Any suggestions for avoiding that kind of incident in the future?

Add clamav to defang's group?