Running locate.service on Debian 13 causes every internal su invocation in updatedb.findutils (including the two select_shell() probes) to produce:

pam_wtmpdb(su:session): add_entry: Adding an entry did not return SQLITE_DONE: 8
pam_lastlog2(su:session): Delete statement did not return SQLITE_DONE: 8

Running the same script manually does not reproduce the issue.

Control: reassign 1142935 libpam-wtmpdb
[...]

Hello Derek,

this does not look like a locate issue. The pam_lastlog2 thing seems to
be  a duplicate of https://bugs.debian.org/1138529 (fixed in upstream
git).  I am reassigning to libpam-wtmpdb, since there is no bug tracking
this there.

cu Andreas

Thanks for the quick response.

I did see that bug, but I'm not convinced it's a duplicate, as the
machine is not loaded and


 > systemctl start locate.service

reproducibly generates


pam_wtmpdb ... SQLITE_DONE: 8 pam_lastlog2 ... SQLITE_DONE: 8


Running /etc/cron.daily/locate directly doesn't create the errors so
it's something to do with the sandbox that systemd is setting up.

But I'm no expert and obviously bow to superior knowledge.

Derek

Hi Derek,

A few interesting things arise from this bug report.
shows the exact reason for the failure:

Jul 28 22:10:14 [su] pam_wtmpdb(su:session): Adding an entry failed: attempt to write a readonly database

2. This points within /usr/lib/systemd/system/locate.service to:

  ProtectSystem=strict

I reproduced this condition absent systemd by running:

  unshare --mount
  mount -o ro /var/log /var/log
  /etc/cron.daily/locate systemd-timer

As you surmise, this is the service hardening tail wagging the
pre-existing functionality dog, in this case not letting a pam module
write to its log files.

One could play whack-a-mole here and open a hole with ReadWritePaths, or
demote ProtectSystem to "=full".

However, I think we can do better.

3. The real worker, /usr/bin/updatedb.findutils, uses 'su' to become
'nobody'. This is not the right way to drop privileges. su is designed
for human users, for a start. util-linux ships with 'runuser' which is
more suitable for system scripts, has a minimal pam configuration and
does not reproduce this problem! I tried this and it works, although it
would need to be considered carefully by the 'locate' maintainers for
unintended consequences.

I suggest this is fixed via a shell function which falls back to 'su' so
that 'locate' can still run on hurd (where there is no systemd anyway).

4. Arguably 'su' shouldn't really be logging to wtmpdb (it doesn't log
to wtmp). Unfortunately there doesn't seem to be sufficient expressivity
in the pam system to exclude one particular module while executing the
rest from '@include common=account'.

However, wtmpdb thought of this and allow one to exclude a service in
the wtmpdb pam config itself. This is done for ssh so that ssh's richer
libwtmpdb integration can be used instead. There is therefore this
workaround possible in /etc/pam.d/common-session:

  session	optional	pam_wtmpdb.so skip_if=sshd,su

This wouldn't fix the 'pam_lastlog2' case but the other resolutions
would.

So, we have three possible user workarounds:

  a) update /etc/pam.d/common.session
  b) copy the unit to /etc/systemd/system/locate.service and create
     a ReadWritePaths hole for /var/log/
  c) copy the unit to /etc/systemd/system/locate.service and change to
     ProtectSystem=full

one bugfix for the locate package:

  d) switch 'su' to 'runas' where available.

and one possible improvement to libpam-wtmpdb:

  e) add 'su' to the skip_if clause in pam config.

I think 'locate' is probably the most accurate home for this bug!

And well done for uncovering the mystery of why I get this in my wtmpdb
every night!

nobody                                 Tue Jun 23 07:35 - 07:38  (00:02)
nobody                                 Tue Jun 23 07:35 - 07:35  (00:00)
nobody                                 Tue Jun 23 07:35 - 07:35  (00:00)

Andrew

Control: reassign -1 locate 4.10.0-3

I do not get hurd issue, while hurd has no systemd it still has runuser.

d)'s "runas" is a typo, and should read "runuser", shouldn't it? (runas
exist, but is very niche and looks dead upstream)

agreed.

cu Andreas

For completeness, my reproducer was missing "--bind" to the mount
command.

Indeed. I falsely assumed that not being Linux, hurd had an alternative
to util-linux that probably didn't have runuser. It seems a direct
substitution would work for the whole of Debian!

Yes, I meant to write 'runuser' but the 'runas' Windowsism crept in.

Thanks.

* Andrew Bower <andrew@bower.uk> [260729 22:29]:
package maintainer hat on). `su` is not meant to be run
non-interactively, even though that was popular in the past.

Another thing: maybe updatedb should not start out as root in the
first place?

Chris

We believe that the bug you reported is fixed in the latest version of
findutils, 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 1142935@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Andreas Metzler <ametzler@debian.org> (supplier of updated findutils 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: Sun, 04 Oct 2026 16:44:43 +0200
Source: findutils
Architecture: source
Version: 4.11.0-3
Distribution: unstable
Urgency: medium
Maintainer: Andreas Metzler <ametzler@debian.org>
Changed-By: Andreas Metzler <ametzler@debian.org>
Closes: 1142935
Changes:
 findutils (4.11.0-3) unstable; urgency=medium
 .
   * Use runuser instead of su in locate's updatedb cronjob.
     Closes: #1142935
Checksums-Sha1:
 f93028f61f75be5416c9b33f8509ddd435a5a78c 2288 findutils_4.11.0-3.dsc
 715e42393083570297a6c45b82292a2dae7fddc3 36056 findutils_4.11.0-3.debian.tar.xz
Checksums-Sha256:
 85f700f9be6c9717117212fd676ffa48f62beaf4c07df3c6f8718b72685c4476 2288 findutils_4.11.0-3.dsc
 64b84d1eb2bee00b20b210a96a78253987b055b290aafa6f9d7b2e7f1e5029c5 36056 findutils_4.11.0-3.debian.tar.xz
Files:
 cf8d8b50c349cff210fa4de4361d9c26 2288 utils required findutils_4.11.0-3.dsc
 6a88ebab256e4c3caa7baa0105163705 36056 utils required findutils_4.11.0-3.debian.tar.xz
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE0uCSA5741Jbt9PpepU8BhUOCFIQFAmrCZ3UACgkQpU8BhUOC
FITsNw/8DEERCdlFFLkWRGEpfJqIFpplpaNzwfChL4nlhHLQ+oKmCmnDOaFlXk3a
W3RmEpw2C1SCP1DLBwM6Q+IUL0i3jxcRG9RdS35mjrljWvsF8AMOd+E32nT28sxU
ga/49wLNYD/C0Pxqwwuh4scYAZzwXNWiuv7BTvXkX7C5F9whhgFxXRLpELgvBm04
eNhMmSp+YH/ihhBrLAesTBKwZH/A4k0+6or2PWqTLpH7zm+AOtrpyu4aQZEeSxfA
sjZXJOsRDvlPq2f8+1NXHmRLWuHL0q2IDrPPJDNALgTyBgk4c+kpKF5oM7M3k6Ex
qkGES3HLMuwsoKCL1Tl2OwDGHzpVGR2gSmMRo7hbzemcZlB6GmyAXDVwTCHEiReG
yXddxOBDk+GIyhgjsZhi79LtTFLtOV6fGrSapos5/oa7ijTEbhPlifiQ2GGT/+AU
nLAyOMzXo89fAXQskGjVp31Q3Q53wqHJfb/dYZlqlhbilkkekPrb7rUCR9yltSJq
mGZMOIUvMsGcJV72gzxnSl8J2EMqd3jdfpm+iknJz4HpI4MFTpZ3qOsSSR5YT8Xz
r7FX+zt50pQHbvQx3PbFLJi4Ativ4FXXjhJvu8NNYmo1jhWDTavFyrwKImss5WnD
iW1PoNzDyYm12ruIgrUoc3y+tiytnHGiXMRc5s87qe8HMcR65io=
=vml+
-----END PGP SIGNATURE-----