libvirt-daemon-system creates system user without marking it as system user for login

Bug #1903509 reported by Mikko Rantalainen
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
libvirt (Ubuntu)
New
Undecided
Unassigned

Bug Description

Package libvirt-daemon-system postinst scripts runs following code:

# Allocated UID and GID for libvirt-qemu
LIBVIRT_QEMU_UID=64055
LIBVIRT_QEMU_GID=64055

...
groupadd --system --non-unique --gid "$gid" libvirt
...

adduser --quiet \
            --system \
            --ingroup kvm \
            --quiet \
            --disabled-login \
            --disabled-password \
            --home /var/lib/libvirt \
            --no-create-home \
            --gecos "Libvirt Qemu" \
            $PARAMETER_UID \
            libvirt-qemu

However, after this has been done, e.g. lightdm will show "Libvirt Qemu" as a possible user to login.

Arguably, the postinst script does the correct thing (it says "--system" and "--disabeld-login") but still package accountsservices picks up this as possible user account to use for login. Perhaps there's some kind of miscommunication between package maintainers about how system accounts are marked as system accounts? At least some packages assume that UID less than 1000 is the only marker for system accounts.

According to 'man adduser' the flag '--system' probably does nothing if UID is hardcoded.

One possible way to fix this would be to include file

    /var/lib/AccountsService/users/libvirt-qemu

with contents

[User]
SystemAccount=true

to package libvirt-daemon-system.

This whole issue is caused by https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844339 which globally reserves UID above 1000 for system level feature.

ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: libvirt-daemon-system 4.0.0-1ubuntu8.17
ProcVersionSignature: Ubuntu 5.4.0-52.57~18.04.1-lowlatency 5.4.65
Uname: Linux 5.4.0-52-lowlatency x86_64
ApportVersion: 2.20.9-0ubuntu7.18
Architecture: amd64
CurrentDesktop: MATE
Date: Mon Nov 9 11:25:56 2020
EcryptfsInUse: Yes
InstallationDate: Installed on 2019-01-05 (673 days ago)
InstallationMedia: Ubuntu 18.04.1 LTS "Bionic Beaver" - Release amd64 (20180725)
SourcePackage: libvirt
UpgradeStatus: No upgrade log present (probably fresh install)
modified.conffile..etc.libvirt.nwfilter.allow-arp.xml: [inaccessible: [Errno 13] Permission denied: '/etc/libvirt/nwfilter/allow-arp.xml']
modified.conffile..etc.libvirt.nwfilter.allow-dhcp-server.xml: [inaccessible: [Errno 13] Permission denied: '/etc/libvirt/nwfilter/allow-dhcp-server.xml']
modified.conffile..etc.libvirt.nwfilter.allow-dhcp.xml: [inaccessible: [Errno 13] Permission denied: '/etc/libvirt/nwfilter/allow-dhcp.xml']
modified.conffile..etc.libvirt.nwfilter.allow-incoming-ipv4.xml: [inaccessible: [Errno 13] Permission denied: '/etc/libvirt/nwfilter/allow-incoming-ipv4.xml']
modified.conffile..etc.libvirt.nwfilter.allow-ipv4.xml: [inaccessible: [Errno 13] Permission denied: '/etc/libvirt/nwfilter/allow-ipv4.xml']
modified.conffile..etc.libvirt.nwfilter.clean-traffic.xml: [inaccessible: [Errno 13] Permission denied: '/etc/libvirt/nwfilter/clean-traffic.xml']
modified.conffile..etc.libvirt.nwfilter.no-arp-ip-spoofing.xml: [inaccessible: [Errno 13] Permission denied: '/etc/libvirt/nwfilter/no-arp-ip-spoofing.xml']
modified.conffile..etc.libvirt.nwfilter.no-arp-mac-spoofing.xml: [inaccessible: [Errno 13] Permission denied: '/etc/libvirt/nwfilter/no-arp-mac-spoofing.xml']
modified.conffile..etc.libvirt.nwfilter.no-arp-spoofing.xml: [inaccessible: [Errno 13] Permission denied: '/etc/libvirt/nwfilter/no-arp-spoofing.xml']
modified.conffile..etc.libvirt.nwfilter.no-ip-multicast.xml: [inaccessible: [Errno 13] Permission denied: '/etc/libvirt/nwfilter/no-ip-multicast.xml']
modified.conffile..etc.libvirt.nwfilter.no-ip-spoofing.xml: [inaccessible: [Errno 13] Permission denied: '/etc/libvirt/nwfilter/no-ip-spoofing.xml']
modified.conffile..etc.libvirt.nwfilter.no-mac-broadcast.xml: [inaccessible: [Errno 13] Permission denied: '/etc/libvirt/nwfilter/no-mac-broadcast.xml']
modified.conffile..etc.libvirt.nwfilter.no-mac-spoofing.xml: [inaccessible: [Errno 13] Permission denied: '/etc/libvirt/nwfilter/no-mac-spoofing.xml']
modified.conffile..etc.libvirt.nwfilter.no-other-l2-traffic.xml: [inaccessible: [Errno 13] Permission denied: '/etc/libvirt/nwfilter/no-other-l2-traffic.xml']
modified.conffile..etc.libvirt.nwfilter.no-other-rarp-traffic.xml: [inaccessible: [Errno 13] Permission denied: '/etc/libvirt/nwfilter/no-other-rarp-traffic.xml']
modified.conffile..etc.libvirt.nwfilter.qemu-announce-self-rarp.xml: [inaccessible: [Errno 13] Permission denied: '/etc/libvirt/nwfilter/qemu-announce-self-rarp.xml']
modified.conffile..etc.libvirt.nwfilter.qemu-announce-self.xml: [inaccessible: [Errno 13] Permission denied: '/etc/libvirt/nwfilter/qemu-announce-self.xml']
modified.conffile..etc.libvirt.qemu.conf: [inaccessible: [Errno 13] Permission denied: '/etc/libvirt/qemu.conf']
modified.conffile..etc.libvirt.qemu.networks.default.xml: [inaccessible: [Errno 13] Permission denied: '/etc/libvirt/qemu/networks/default.xml']

Revision history for this message
Mikko Rantalainen (mira) wrote :
Revision history for this message
Mikko Rantalainen (mira) wrote :

The warnings about files in /etc/libvirt/nwfilter/* could also be considered as a bug. Those files are automatically generated and I haven't modified those files. If libvirt is supposed to take care of these files they probably belong under /var/lib/libvirt instead of /etc/libvirt.

Revision history for this message
Mikko Rantalainen (mira) wrote :

Note that according to base-passwd package

You *may not* use any uids or gids in the 60000-64999 range without *first*
requesting an allocation from <email address hidden> and waiting

so perhaps libraries that tell if an user account is system or not, need to check if UID is in range from FIRST_SYSTEM_UID to LAST_SYSTEM_UID *or* if it's in range 60000-64999.

In case the UID is in range 60000-64999, a custom lookup should be made to decide if any given UID in this range is a system account or user account. I'm not familiar with the way all those reserved UIDs are used but I'd assume that any UID in that range is special and may require UID specific knowledge about being normal vs system account.

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

Hi Mikko,
this unfortunate behavior was discussed a few times already. The central bug for it is bug 857651.
It isn't so much a bug in the libvirt package as much more accountservice it seems. Depending on the version and type of your Desktop environment it is already gone.

See the bug there for some history about it please - marked as a dup.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.