Dear Maintainer,

since I've upgraded systems to trixie, logcheck mails me daily system events like these:

Jun 27 00:01:21 hostname chkrootkit-daily[2588815]: sending alert to root: [chkrootkit] alert for hostname.example.org
Jun 27 00:01:21 hostname chkrootkit-daily[2589917]: mail: /tmp/mail.RsXXXX8kWKZT: Read-only file system

That is while:
- the system can send mails
- /tmp is writable
- chkrootkit reports no issues

Obviously I can rather easily ignore those in logcheck but I would like to know
what's going on first. Do you have any idea?

Thanks for maintaining chkrootkit!

read-only when the unit runs: However, we set
Environment=TMPDIR=/run/chkrootkit which should mean things dont write
to /tmp --- maybe your email sending setup ignores TMPDIR? are you
using something non-standard?

You should be able to fix this with running systemctl edit chkrootkit
and making a drop-in with

[Service]
ReadWritePaths=/tmp

That should fix it. Depending on how unusual your system is, we might
want to add this for trixie, (or maybe disable the protectsystem)

(If that's not it, it may be another instance of #1106030, but it
looks different)

Either way you probably shouldn't ignore these lines with logcheck: it
looks like it is trying to email you and failing

On Mon, 30 Jun 2025 at 19:26, Richard Lewis <richard.lewis.debian@googlemail.com> wrote:

just remembered -- this is not an ideal solution for most users: a
read-only /tmp was added to prevent all files in /tmp being marked as
"used" by the scan as that would defeat systemd's automatic "cleanup"
of /tmp.

So we really dont want to revert this setting (which was added in
february to fix #1089588) --- we really want to find a way to make the
mail system not use /tmp

(I'll reply with more details eventually...)

thanks for your reply! The mail system is a fairly standard postfix setup
and it can send mails. I do receive logcheck mails..

control: severity -1 serious
thanks

I can send mail on these machines using this command:

$ date| mail -s test root

indeed, hence I'm raising the severity. (Because I believe that warning about
probs is chkrootkit's basic function. Feel free to downgrade, I don't mind.)

Also because I'm seeing this on systems running postfix and (others) running
ssmtp.

great --  but this isnt sending mail from a systemd unit with a read-only
/tmp or with a different TMPDIR setting

--- does the systemd workaround in the earlier message work?

--- does running /sbin/chkrootkit-daily directly work? (just in case)

can you also tell me

--- how to configure a system to reproduce this in a new container: what
packages do i install (postfix? ssmtp? please assume.no knowledge of
these!) and what settings to make (if any? i think we would just need
"local delivery"): this seems like something we will need to test more,
however we reaolve this

--- what provides mail(1) --is it mailx or mailutils etc? (probably doesnt
matter, but.)

thats with a writable /tmp

I havent tried cause you said you rather dont want that.

yes

either

i've configured postfix and ssmtp to send mail to a smarthost.

bsd-mailx

it also does send an email. :)

i'm not sure, but i think this may be the problem --- looking at
https://salsa.debian.org/debian/bsd-mailx/-/blob/master/send.c and
https://salsa.debian.org/debian/bsd-mailx/-/blob/master/debian/patches/02-Base-fixes-1.patch
it seems debian has patched bsd-mailx to hardcode /tmp (im not sure
about this, i only read the code on salsa, and couldnt spot where the
directory was set)?

does it work to use mailutils instead?

does editing /sbin/chkrootkit-daily to use sendmail fix it  (something
like this):

@@ -105,7 +105,11 @@ if [ -s "$FILE" ]; then
            # run by systemd: product a line on stdout for the journal
            echo "sending alert to $MAILTO: $SUBJECT"
        fi
-       mail -s "$SUBJECT" "$MAILTO" < "$FILE"
+       {
+         echo "$SUBJECT"
+         echo
+         cat "$FILE"
+       } | sendmail "$MAILTO"

control: reassign -1 bsd-mailx
control: debian has patched bsd-mailx to hardcode /tmp
control: affects -1 logcheck
thanks

ic!

installing it on a system atm. didnt help, because i also had to remove
bsd-mailx. then it worked \o/

i'd rather not edit files in /sbin :)

thanks!

Hi everyone,

I've come along and done the easy bit... the attached patch causes mailx
to honour the TMPDIR environment variable, if set. Does this do enough
to fix your originally-failing scenario?

(I don't see that Debian overrode anything so much as setting an
otherwise undefined but required build-time definition for the default.)

Andrew

Thanks - this looks a good solution to me

I tested a bsd-mailx with your patch applied in a systemd-nspawn
container (unstable), with exim, and it fixed the original issue
(which i could reproduce)

i also installed postfix and it continued to work (but i didnt try
this with the unpatched bsd-mailx).
i tried to install ssmtp but it failed to install (seems unrelated,
but i didnt investigate)

ah yes!

Control: retitle -1 bsd-mailx: allow TMPDIR env to override /tmp

Fantastic! (I know I'm a total fraud offering to help at this last
stage when you had done all the work but I couldn't resist...)

I've placed a suitable source package on mentors for convenience in case
it's not possible to reach the maintainer in a timely fashion with
corresponding git commits also available:

https://mentors.debian.net/package/bsd-mailx/
https://salsa.debian.org/abower/bsd-mailx/-/commits/honour-tmpdir

I suspect a pre-request will not be needed for this change?

[...]

I'm retitling to reflect - hope that's ok!

great!

(fwiw, i currently cannot access the systems were i have been seeing this problem...)

I have raised a sponsorship request [1] and an unblock request [2] for
an NMU to fix this in case the package maintainer is not currently able
to take over this issue quickly at this stage in the freeze.

Hope this helps!

[1] RFS: https://bugs.debian.org/1109081
[2] unblock: https://bugs.debian.org/1109085

We believe that the bug you reported is fixed in the latest version of
bsd-mailx, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 1108377@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Andrew Bower <andrew@bower.uk> (supplier of updated bsd-mailx package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Wed, 09 Jul 2025 23:03:16 +0100
Source: bsd-mailx
Architecture: source
Version: 8.1.2-0.20220412cvs-1.1
Distribution: unstable
Urgency: medium
Maintainer: Robert Luberda <robert@debian.org>
Changed-By: Andrew Bower <andrew@bower.uk>
Closes: 1108377
Changes:
 bsd-mailx (8.1.2-0.20220412cvs-1.1) unstable; urgency=medium
 .
   * Non-maintainer upload.
   * Patch to honour TMPDIR. (Closes: #1108377)
     Thanks: Richard Lewis, Holger Levsen.
Checksums-Sha1:
 259cb48caa226d9aa1644bbe06ab59985b319ac0 1586 bsd-mailx_8.1.2-0.20220412cvs-1.1.dsc
 d771bb740bfb0ba938f7ff487bb013cc8b2831a4 49836 bsd-mailx_8.1.2-0.20220412cvs-1.1.debian.tar.xz
 7834a11195855e7bbc3e2fd7ce26a8ba199373a1 5721 bsd-mailx_8.1.2-0.20220412cvs-1.1_source.buildinfo
Checksums-Sha256:
 e260dc101ecf4b5f3c5ec902ae45c4cbf210e10bcb0800f81d467fa36a73c040 1586 bsd-mailx_8.1.2-0.20220412cvs-1.1.dsc
 f2743b28ec1e3822e914575c3677669041ea97abf3ce454a269859d287c1c364 49836 bsd-mailx_8.1.2-0.20220412cvs-1.1.debian.tar.xz
 6bf2d4b477c8e3fc4d577a69be87c7a0d299523d8c407c28d8f72f8085c8ad99 5721 bsd-mailx_8.1.2-0.20220412cvs-1.1_source.buildinfo
Files:
 f001e20fd394ccb1e7e0cf88c2749363 1586 mail optional bsd-mailx_8.1.2-0.20220412cvs-1.1.dsc
 fde3385e2643b0980a1e59f6a181bc68 49836 mail optional bsd-mailx_8.1.2-0.20220412cvs-1.1.debian.tar.xz
 fc606697974c66264d95c7a15bee9288 5721 mail optional bsd-mailx_8.1.2-0.20220412cvs-1.1_source.buildinfo
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEE9ecZmu9eXGflVYc/dA1oiINl0okFAmhz+i8ACgkQdA1oiINl
0onAJgf+PPrsTE2/OxuwumL+CnDe3vZ9io8dIbqigpbEUDjomorkkPJ9uWF2TOEG
g6OA2MDe1DhM8ghWey73Vy+rGRkGqN7NOkxDXfNGU43W7LFTB3JXsxU1l6qmfVTu
Fwk8UKiafLOJ/Y0xUhTNvybh0sYMyJxAEfDKhHcTt7LMqr2CtU1cOBAbMNpfsV8E
ELUhLMZDF6lp8ocCX8XRo8Vf4NydIK5iXe3SIXwoLAyU1YipS+qObx2C7pJMFGMn
uswThVAhu9KOC8vK649hiJXifmUhgrJ9KQrjb2ooEM3DPUyPj86iSl9HIEVR2Bfz
6b6bJsQFzHds8rSKqAY0t9UqApX4CA==
=dDZb
-----END PGP SIGNATURE-----