Problem with polkitd.postinst:

"getent passwd polkitd" can fail, even though polkitd can be found
in /etc/passwd.


Regards

Harri

In what situation does this fail?

If you have a better suggestion, please propose a patch?

Thanks,
    smcv

Hi Simon,

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.

I stumbled over this during the upgrade Debian 11 --> 12 in a chroot.
Somehow polkitd couldn't be installed because the polkitd user and group
were missing. Actually I am not sure how this happened, but after
manually adding local user and group entries for polkitd installation
succeeded.

Regards
Harri

I was able to reproduce the problem in a chroot, using the postinst
script with "set -x", and even though the previously suggested fix
was applied:

:
Setting up polkitd (122-4~xgo120+1) ...
+ set -e
+ case "$1" in
+ getent -s files passwd polkitd
+ user_changed=yes
+ command -v systemd-sysusers
+ systemd-sysusers polkitd.conf
Failed to check if group polkitd already exists: Connection refused
+ dpkg --compare-versions '' lt 122-3~
++ getent -s files passwd polkitd
++ cut -d: -f6
+ '[' '' = /var/lib/polkit-1 ']'
++ id -g polkitd
id: 'polkitd': no such user
+ '[' '' = 65534 ']'
+ set_perms polkitd root 700 /etc/polkit-1/rules.d
+ USER=polkitd
+ GROUP=root
+ MODE=700
+ FILE=/etc/polkit-1/rules.d
+ dpkg-statoverride --list /etc/polkit-1/rules.d
+ chown polkitd:root /etc/polkit-1/rules.d
chown: invalid user: 'polkitd:root'
dpkg: error processing package polkitd (--configure):
  installed polkitd package post-installation script subprocess returned error exit status 1
:

Apparently the code around systemd-sysusers is to blame here. I
would guess it could not access the remote user database (LDAP/
Kerberos).

Note that the policy-rc.d script was set accordingly for a chroot:

	# cat /usr/sbin/policy-rc.d
	#!/bin/sh
	exit 101


Hope this helps

Harri

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?

In any case, as per your later reply, it seems that this wouldn't have
been sufficient:

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

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.

This is what is actually causing the script to fail here, and it's
unavoidable: we can't not do this. If we skipped this step, polkitd
would not work correctly.

(In current versions of polkitd it would be root:polkitd, but the
principle is the same.)

chown, id and any other standard system utilities that use glibc
interfaces like getpwnam() are always going to do the equivalent of
`getent passwd polkitd` and never the equivalent of
`getent -s files passwd polkitd`, so the equivalents of those calls need
to work, one way or another, while you are doing your upgrade.

    smcv

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?

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.

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?


Regards

Harri

Sorry I do not understand hw this explain in what situatoin `getent
passwd polkitd` fails when polkitd user is in /etc/passwd.
Could you be more specific?
LDAP
group

If it works in a chroot after adding the polkitd user to /etc/passwd
this might be another issue (ie one where polkitd is not in /etc/passwd
). Could you confirm?


Could it be that polkitd user was missing from /etc/passwd in the first
place and the `getent` code was OK?
So the issue would be why polkitd ended up missing in /etc/passwd.

I do not see how other NSS databases could relate to this issue. If
polkitd was in /etc/passwd, with or without other NSS DBs "getent
passwd  polkitd" should work>.
Does `getent -s files passwd polkitd` really worked while `getent
passwd polkitd` did not?

Regards,
Alban

Hi Alban,

sorry, I cannot reproduce this anymore: In the meantime I have migrated
all my hosts to bookworm. When I ran into this problem, I have manually
created a local user and tried the upgrade again. Worked for me.

See the debug output in my posting in this thread of Dec 15th.


Regards

Harri

Am 22.01.24 um 15:54 schrieb Harald Dunkel:

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

I would suggest to simply create polkitd user and group using useradd
instead of systemd, ignore the error message indicating the user exists
or whatever might happen, and then try to use the polkitd user. If this
last step fails, then the postinst script can exit with an error.

I don't know of any other package (except for systemd) using systemd-sysusers
in its maintainer scripts, but I've got 33 packages using useradd or
adduser just on my Linux desktop. IMHO this approach would be reasonable.

Closing the ticket is fine with me.


Regards

Harri

Am 29.02.24 um 15:10 schrieb Harald Dunkel:

apt-file search /usr/lib/sysusers.d will tell you which packages use
sd-syusers.


$ apt-file search /usr/lib/sysusers.d/ | wc -l
43

So yeah, if there is a problem with sd-sysusers, it should be addressed,
as this interface is becoming more ubiquitous.

So if you have a good reproducer and a debug log, please let us know and
we will reopen this bug report.

Michael