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
** Tags removed: server-next
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1875926
Title:
snmpd upgrade (Bionic->Focal) changes Debian-snmp UID/GID
To manage notifications about this bug go to:
htt
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
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.
--
You rece
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.
** Changed in: net-snmp (Ubuntu
FYI - Uploaded to the SRU queue in Bionic
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1875926
Title:
snmpd upgrade (Bionic->Focal) changes Debian-snmp UID/GID
To manage notifications about this b
** Description changed:
[Impact]
- * Removeing users on "remove" instead of doing so only on "purge"
-can lead to some fallout.
+ * 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 sam
** Description changed:
- snmpd upgrade bionic->focal changes Debian-snmp UID/GID. Tested on two
- different machines, the result:
+ [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
** Merge proposal linked:
https://code.launchpad.net/~paelzer/ubuntu/+source/net-snmp/+git/net-snmp/+merge/383776
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1875926
Title:
snmpd upgrade (Bion
** Changed in: net-snmp (Ubuntu Bionic)
Status: Confirmed => Triaged
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1875926
Title:
snmpd upgrade (Bionic->Focal) changes Debian-snmp UID/GID
To
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.
--
You received this
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.
** Tags added: bitesize server-next
--
You received this bug notification because you are
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 th
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/.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscr
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
15 matches
Mail list logo
