Subject: eudev: postinst fails when kvm group present

From: Meeuwissen Olaf <[email-masked]>
Date: Mon, 15 Feb 2021 00:58:27 +0000

Package: eudev
Version: 3.2.9-8~beowulf1
Severity: normal

Dear Maintainer,

I just upgraded a number of packages on a machine where I had
manually added a `kvm` group.  This caused the postinst script
to fail with

  The group `kvm' already exists and is not a system group. Exiting.

leaving `eudev` unconfigured.

I don't know if the `kvm` *must* be a system group but things 
have been working fine for me with a non-system group.  As long as
a non-system `kvm` group exists, configuring `eudev` will fail.
This is easily confirmed with

  $ sudo dpkg-reconfigure eudev
  The group `kvm' already exists and is not a system group. Exiting.

Changing the group to a system group fixes this behaviour.

I worked around the issue by appending `|| true` in the postscript
to the `adduser` command that tries to create the system group.

If the `kvm` group does not have to be a system group, I would expect
configuration to succeed if a non-system `kvm` group is present.

-- Package-specific info:

-- System Information:
Architecture: x86_64

Kernel: Linux 4.19.0-14-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages eudev depends on:
ii  adduser      3.118
ii  debconf      1.5.71
ii  libblkid1    2.33.1-0.1+devuan1~beowulf2
ii  libc6        2.28-10
ii  libeudev1    3.2.9-8~beowulf1
ii  libkmod2     26-1
ii  libselinux1  2.8-1+b1
ii  lsb-base     10.2019051400
ii  procps       2:3.3.15-2+devuan1
ii  util-linux   2.33.1-0.1+devuan1~beowulf2

eudev recommends no packages.

eudev suggests no packages.

-- no debconf information

---

From: Bob Proulx <[email-masked]>
Date: Wed, 17 Feb 2021 15:05:43 -0700

severity 548 important
thanks

> leaving `eudev` unconfigured.

I noticed this on Sunday and also investigated.  And then today
another user DeepDive on #devuan IRC reported the same problem.
Therefore I am raising the severity to important due to the effect
this has for many users.

> configuration to succeed if a non-system `kvm` group is present.

But the code used in the postinst is problematic.  The code is this.
(I know the web version does not show indentation.  Imagine the code
being indented.  Check the original files.)

    #!/bin/sh
    set -e
    ...
    case "$1" in
        configure)
        ...
        # Add new system group used by udev rules
        addgroup --quiet --system input

        # Make /dev/kvm accessible to kvm group
        addgroup --quiet --system kvm

        # Make /dev/dri/renderD* accessible to render group
        addgroup --quiet --system render

Those are unconditional additions.  Which means that if the addgroup
returns a non-zero exit code then due to the set -e the configure
fails and the package is left unconfigured.

It is true that the addgroup would return 0 (success) if it would not
need to do the action.  But if the user has already locally configured
an account user or group then that previously existing configuration
should be maintained.

Therefore group addition should not be unconditional.  It should be
conditional upon the group not already existing.  I present two
alternative examples from existing packages that handle this in two
different ways.

The first from postfix.  The "try it and see" method.

    cd ${CHROOT}
    # make sure that the postfix user exists.  Simplest portable way to check is to
    # chown something, so we'll create the directories that we need here.
    makedir private         root:root 700
    chgrp postfix private 2>/dev/null ||
        addgroup --system postfix
    chown postfix private 2>/dev/null ||
        adduser --system --home ${CHROOT} --no-create-home --disabled-password --ingroup postfix postfix

The second from libvirt-daemon-system.  The "check it and see" method.

    if ! getent group libvirt >/dev/null; then
        addgroup --quiet --system libvirt
    fi
    if ! getent group kvm >/dev/null; then
        addgroup --quiet --system kvm
    fi

Again for the web display please imagine the above having indentation.

And so either way seems good and acceptable.  I would probably do the
same thing libvirt-daemon-system is doing as that is simple enough.
Here is a suggested fix for this.

    # Add new system group used by udev rules
    if ! getent group input >/dev/null; then
        addgroup --quiet --system input
    fi

    # Make /dev/kvm accessible to kvm group
    if ! getent group kvm >/dev/null; then
        addgroup --quiet --system kvm
    fi

    # Make /dev/dri/renderD* accessible to render group
    if ! getent group render >/dev/null; then
        addgroup --quiet --system render
    fi

Thank you for maintaining eudev in Devuan! :-)

Bob

---

From: Meeuwissen Olaf <[email-masked]>
Date: Wed, 17 Feb 2021 23:15:46 +0000

> Therefore I am raising the severity to important due to the effect

Thanks.  I was wondering whether to do so on the initial report.

> same thing libvirt-daemon-system is doing as that is simple enough.

I would also go the libvirt-daemon-system way.  It more clearly states
what is going on.

> Thank you for maintaining eudev in Devuan! :-)

And thank you for actually suggesting a fix!

Hope this helps,
--
Olaf Meeuwissen, LPIC-2       FLOSS Engineer -- EPSON AVASYS CORPORATION
       Free Software Foundation Associate Member since 2004-01-27
    Support Free Software                  https://my.fsf.org/donate
    Join the Free Software Foundation        https://my.fsf.org/join

---

From: Ralph Ronnquist <[email-masked]>
Date: Sun, 21 Feb 2021 23:00:43 +1100

You'll need to make sure the kvm group has a gid > 1000.

E.g. edit /etc/group and change the kvm line from say 106 to 10666, then

# apt-get install --reinstall eudev

fails with:
----
The group `kvm' already exists and is not a system group. Exiting.
dpkg: error processing package eudev (--configure):
 installed eudev package post-installation script subprocess returned error exit status 1
Processing triggers for man-db (2.8.5-2) ...
Errors were encountered while processing:
 eudev
E: Sub-process /usr/bin/dpkg returned an error code (1)
----

---

From: Svante Signell <[email-masked]>
Date: Sun, 21 Feb 2021 17:44:25 +0100

> E: Sub-process /usr/bin/dpkg returned an error code (1)

Problem is if non-system groups: input, kvm and render should be
allowed or not. The whole idea of system group names is that these
names should be reserved?? WDYT?

---

From: Olaf Meeuwissen <[email-masked]>
Date: Mon, 22 Feb 2021 08:52:54 +0900

Hi,

>> You'll need to make sure the kvm group has a gid > 1000.

Mostly correct.  My original report mentioned I had a regular group as
opposed to a system group.  The exact ranges for these are customizable
but the defaults are such that regular groups get 1000-60000.
BTW, the defaults are in /etc/login.defs.  You're looking for GID_MIN
and GID_MAX.  The system group values, SYS_GID_MIN and SYS_GID_MAX are
mentioned in comments.

> names should be reserved?? WDYT?

I also mentioned this possibility, that kvm might have to be a system
group, in my original issue but could not find any definitive list of
system groups in Debian Policy and didn't look elsewhere.

If these groups must be system groups, then I think the right thing to
do is to log the discrepancy, change the group's ID *and* reassign the
group for all file system entries that have the old ID.

For the time being, I am still using my regular kvm group, i.e. with a
GID > 1000.

Hope this helps,
--
Olaf Meeuwissen, LPIC-2            FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Software                        https://my.fsf.org/donate
 Join the Free Software Foundation              https://my.fsf.org/join