snmpd upgrade (Bionic->Focal) changes Debian-snmp UID/GID

[Dariusz Kolasinski]

[Impact]

 * Removeing users on "remove" instead of doing so only on "purge"
   can lead to some fallout.

 * We stopped doing so since 18.10, backporting the same fix to Bionic

[Test Case]

 * apt install snmpd
 * grep snmp /etc/passwd
 * apt remove snmpd
 * grep snmp /etc/passwd
 * apt install snmpd
 * grep snmp /etc/passwd

 With the fix installed this should not change the UID anymore when running
 the above and also not vanish in between.

[Regression Potential]

 * It was wrong to re-create the user every time, I don't see an issue "not
   to remove it" on apt remove - if people want things gone they are using
   "apt purge".
   If anything first installs net-snmp, to then remove it and expects the
   Debian-snmp is free that would change - but that seems like a very
   constructed case.

 * The real "potential" is that any upgrade will trigger the bug "once".
   That includes this update - see below in [Other Info]

[Other Info]

 * No matter which way we turn this, this bug will be triggered "once" when
   the old postrm is run. We don't need/want to trigger it with this
   update. Therefore the intention is to only make this available in -
   proposed and mark it as block-proposed. On any later functional or
   security update which would trigger the bug "anyway" it would then be
   included and fixed.

---

snmpd upgrade bionic->focal changes Debian-snmp UID/GID. Tested on two different machines, the result:

#1

diff -u passwd.r15 passwd.local
--- passwd Rev. 15 (Fri Sep 13 10:35:32 2019)
+++ passwd Local version (Fri Apr 24 09:53:12 2020)
@@ -31,4 +31,6 @@ systemd-resolve:x:112:122:systemd Resolv
 uuidd:x:100:101::/run/uuidd:/bin/false
 _apt:x:114:65534::/nonexistent:/bin/false
 dhcpd:x:115:125::/var/run:/bin/false
-Debian-snmp:x:109:118::/var/lib/snmp:/bin/false
+tcpdump:x:109:126::/nonexistent:/usr/sbin/nologin
+Debian-snmp:x:113:127::/var/lib/snmp:/bin/false
+systemd-coredump:x:999:999:systemd Core Dumper:/:/usr/sbin/nologin

#2

--- passwd Rev. 5 (Thu Feb 20 15:21:15 2020)
+++ passwd Local version (Wed Apr 29 17:28:58 2020)
@@ -31,6 +31,9 @@ postfix:x:111:114::/var/spool/postfix:/u
 bacula:x:112:116:Bacula:/var/lib/bacula:/usr/sbin/nologin
 mysql:x:113:117:MySQL Server,,,:/nonexistent:/bin/false
 nagios:x:114:118::/var/lib/nagios:/usr/sbin/nologin
-Debian-snmp:x:115:119::/var/lib/snmp:/bin/false
 elasticsearch:x:116:120::/nonexistent:/bin/false
 str_alk_prod:x:1000:1000:,,,:/home/str_alk_prod:/bin/bash
+systemd-timesync:x:115:119:systemd Time Synchronization,,,:/run/systemd:/usr/sbin/nologin
+tcpdump:x:117:123::/nonexistent:/usr/sbin/nologin
+Debian-snmp:x:118:124::/var/lib/snmp:/bin/false
+systemd-coredump:x:999:999:systemd Core Dumper:/:/usr/sbin/nologin

[Paride Legovini (paride)]

Hi Dariusz, thanks for filing this bug report. While the UID/GID do indeed change, it seems to be that the ownership of files and directories is handled correctly, at least from the very simple testing I performed. Could you please state more explicitly what problem you are facing?

I'm setting the status of this report to Incomplete for the moment; please set it back to New after replying and we'll look at it again. Thanks!

[Dariusz Kolasinski (offcer)]

The trouble is that the UID/GID of files owned by Debian-snmp (before the upgrade) is kept resulting in files owned by tcpdump and systemd-timesync after the upgrade. For egzample files in /etc/snmp/.

[Christian Ehrhardt  (paelzer)]

Bionic on install:
# grep snmp /etc/passwd
Debian-snmp:x:111:115::/var/lib/snmp:/bin/false

That is by:
        adduser --quiet --system --group --home "$SNMP_DIR" \
                --disabled-password --disabled-login \
                --shell "$SNMP_SHELL" --force-badname "$SNMP_USER"

ANd of the install owned is only:
# find / -group Debian-snmp 2>/dev/null
/var/lib/snmp
/var/lib/snmp/snmpd.conf

While /etc/snmp/* is root owned.

After upgrade to Focal I see:
# grep snmp /etc/passwd
Debian-snmp:x:112:118::/var/lib/snmp:/bin/false

/var/lib/snmp will be re-owned by the postinst script and I indeed see that it still matches.
/etc/sndmp still is root owned.

So nothing but /var/lib/snmpd should actually be owned by that user - and that path is taken care of. Were the files in /etc/snmpd required to be owned by that user or was it an accident or misconfiguration?

BTW - the reason that the user changes is due to [1][2] and fixed since Ubuntu 19.04 in version 5.7.3+dfsg-5ubuntu1 and later. It will no more change later on.

If there is a real reason that other files than those in /var/lib/snmpd need to be owned by Debian-snmpd then we need to consider backporting the fix to Bionic. But this is a hard call to make as it is a double-edged sword. The fact that we would do a Bionic SRU will itself trigger this bug in the postrm of the current snmpd package. So while the bug would be fixed fromt hen on, it would instantly trigger it once for anyone else that wasn't affected until then.

Note: this might be a perfect case for block proposed thou, prepare the change and hold it in bionic-proposed. But only release it with the next actual critically required fix.

For now I'm looking for some feedback by net-snmpd users if anything other then /var/lib/snmpd should ever be owned by that user to better consider the severity of it.

[1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911216
[2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911132
[3]: https://salsa.debian.org/debian/net-snmp/-/commit/f406c84fb2f350bc3663401d0d764bbad9ae51b6

[Christian Ehrhardt  (paelzer)]

Subscribing ubuntu-server at low prio, until we know more.
If it is more common than expected it can become higher prio.
But actually preparing it in block-proposed qualifies as server-next+bitesize IMHO.

[Dariusz Kolasinski (offcer)]

OK, I understand now. It looks like my configuration is affected. I keep some configuration files in /etc/snmp needed for snmp modules (like database integration etc.). This files need to be Debain-snmp group readable. I also keep some local state data in /usr/local/var/snmp.

[Christian Ehrhardt  (paelzer)]

FYI - Uploaded to the SRU queue in Bionic

[Robie Basak (racb)]

Thanks - this looks appropriate. To clarify my understanding, if an update to net-snmp happens in Bionic then the bug will happen when users upgrade to that anyway. So using block-proposed-bionic will not make anything worse, but will fix the problem for next time.

[Robie Basak (racb)]

Hello Dariusz, or anyone else affected,

Accepted into bionic-proposed. The package will build now and be available in a few hours in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Christian Ehrhardt  (paelzer)]

Yes Robie,
the bug will happen on whatever the upgrade is:
- upgrade to Focal
- upgrade to a bugfix or security upload to Bionic
- ...

Putting this in -proposed will make sure it does not trigger now (as we don't release it) but only one last time on whatever the next upload will be.

[Christian Ehrhardt  (paelzer)]

Old:
 * apt install snmpd
 * grep snmp /etc/passwd
 * apt remove snmpd
 * grep snmp /etc/passwd
 * apt install snmpd
 * grep snmp /etc/passwd

With:
     5.7.3+dfsg-1.8ubuntu3.4 500
        500 http://archive.ubuntu.com/ubuntu bionic-proposed/main amd64 Packages
        100 /var/lib/dpkg/status

# grep snmp /etc/passwd
Debian-snmp:x:112:119::/var/lib/snmp:/bin/false
root@b:~# apt remove snmpd
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages were automatically installed and are no longer required:
  libsensors4 libsnmp-base libsnmp30
Use 'apt autoremove' to remove them.
The following packages will be REMOVED:
  snmpd
0 upgraded, 0 newly installed, 1 to remove and 22 not upgraded.
After this operation, 144 kB disk space will be freed.
Do you want to continue? [Y/n] Y
(Reading database ... 37984 files and directories currently installed.)
Removing snmpd (5.7.3+dfsg-1.8ubuntu3.4) ...
Processing triggers for man-db (2.8.3-2ubuntu0.1) ...
root@b:~# grep snmp /etc/passwd
Debian-snmp:x:112:119::/var/lib/snmp:/bin/false

It is stying around as intended.

Purge still clears
root@b:~# apt remove --purge snmpd
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages were automatically installed and are no longer required:
  libsensors4 libsnmp-base libsnmp30
Use 'apt autoremove' to remove them.
The following packages will be REMOVED:
  snmpd*
0 upgraded, 0 newly installed, 1 to remove and 22 not upgraded.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n] Y
(Reading database ... 37966 files and directories currently installed.)
Purging configuration files for snmpd (5.7.3+dfsg-1.8ubuntu3.4) ...
Processing triggers for systemd (237-3ubuntu10.40) ...
Processing triggers for ureadahead (0.100.0-21) ...
root@b:~# grep snmp /etc/passwd

In comparison install/remove/installing the old version removed the users.

root@b:~# apt install snmpd=5.7.3+dfsg-1.8ubuntu3.3 libsnmp30=5.7.3+dfsg-1.8ubuntu3.3
Reading package lists... Done
Building dependency tree
Reading state information... Done
Suggested packages:
  snmptrapd
The following NEW packages will be installed:
  snmpd
The following packages will be DOWNGRADED:
  libsnmp30
0 upgraded, 1 newly installed, 1 downgraded, 0 to remove and 22 not upgraded.
Need to get 986 kB of archives.
After this operation, 144 kB of additional disk space will be used.
Do you want to continue? [Y/n] Y
Get:1 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 libsnmp30 amd64 5.7.3+dfsg-1.8ubuntu3.3 [929 kB]
Get:2 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 snmpd amd64 5.7.3+dfsg-1.8ubuntu3.3 [57.0 kB]
Fetched 986 kB in 1s (1767 kB/s)
Preconfiguring packages ...
dpkg: warning: downgrading libsnmp30:amd64 from 5.7.3+dfsg-1.8ubuntu3.4 to 5.7.3+dfsg-1.8ubuntu3.3
(Reading database ... 37962 files and directories currently installed.)
Preparing to unpack .../libsnmp30_5.7.3+dfsg-1.8ubuntu3.3_amd64.deb ...
Unpacking libsnmp30:amd64 (5.7.3+dfsg-1.8ubuntu3.3) over (5.7.3+dfsg-1.8ubuntu3.4) ...
Selecting previously unselected package snmpd...

[Launchpad Janitor (janitor)]

This bug was fixed in the package net-snmp - 5.7.3+dfsg-1.8ubuntu3.5

---------------
net-snmp (5.7.3+dfsg-1.8ubuntu3.5) bionic-security; urgency=medium

  * SECURITY UPDATE: Elevation of privileges - symlink handling
    - debian/patches/CVE-2020-15861.patch: stop reading and writing
      the mib_indexes files in include/net-snmp/library/mib.h,
      include/net-snmp/library/parse.h, snmplib/mib.c, snmplib/parse.c.
    - CVE-2020-15861
  * SECURITY UPDATE: Elevation of privileges
    - debian/patches/CVE-2020-15862.patch: make the extend mib
      read-only by default in agent/mibgroup/agent/extend.c.
    - CVE-2020-15862

 -- <email address hidden> (Leonidas S. Barbosa) Mon, 17 Aug 2020 16:16:25 -0300