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