Am 22.01.24 um 15:54 schrieb Harald Dunkel:
On 2024-01-22 12:41:04, Simon McVittie wrote:
On Thu, 14 Dec 2023 at 11:38:16 +0100, Harald Dunkel wrote:
getent queries all databases, as listed in /etc/nsswitch.conf, AFAIU.
I would suggest to use

    getent -s files passwd polkitd

to query /etc/passwd only and to ignore remote databases based on LDAP
or NIS or similar. polkitd is supposed to be a local system user.

Wouldn't this break systems where polkitd is a local system user stored
in some backend other than the standard flat files, like libnss-db or
libnss-extrausers?


I can't help it. The getent was just a suggestion. Maybe it would be wise
to ignore all local and remote databases for creating system accounts,
except for the traditional files in /etc?


How is this particular system set up? Is it using a remote user database?


It would be using a remote database (FreeIPA, i.e LDAP), but this is a
chroot. I am updating a clone of the root partition from Debian 11 to
12 to reduce the downtime. /usr/sbin/policy-rc.d is set accordingly.

There is no polkitd account in the remote database, anyway. I checked.

This seems to be consistent with how
/usr/share/debhelper/autoscripts/postinst-sysusers handles sysusers, so
if there is a bug here, it would affect any package that relies on
sysusers.d, not just polkit.

I have updated quite a number of hosts already, but only polkitd postinst
in Debian 12 ran into this problem. The fix is to manually add polkitd
to the local database on the command line (copy and paste from the
postinst script:

             adduser --group --system --gecos 'polkit' \
                 --no-create-home --home /nonexistent polkitd

) and to try again.

Looking at the code

         if command -v systemd-sysusers >/dev/null; then
            systemd-sysusers ${DPKG_ROOT:+--root="$DPKG_ROOT"} polkitd.conf
         else
             adduser --group --system --gecos 'polkit' \
                 --no-create-home --home /nonexistent polkitd
             addgroup --system polkitd
         fi

I wonder if the systemd case would be executed in a chroot?

systemd-sysusers is executed in a chroot. It's a standalone tool that doesn't require a running systemd.

It would be interesting to get the output of
SYSTEMD_LOG_LEVEL=debug systemd-sysusers polkitd.conf

But you wrote later, that you can no longer reproduce the issue yourself. So I guess we should close this issue at this point as we don't have enough information to further investigate this.

I do remember https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1059216
where polkitd.postinst also failed.
It turned out though, that the users had a broken/malformatted /etc/gshadow file and systemd-sysusers is apparently a bit more picky in that regard then adduser.

Regards,
Michael


Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature

Reply via email to