fixed in mga7:

src:
    - unbound-1.10.1-1.1.mga7

CC: (none) => mageia
Assignee: eatdirt => qa-bugs
Status comment: Patch available from upstream and Debian => (none)

Advisory:
========================

Updated unbound packages fix security vulnerability:

Unbound contains a local vulnerability that would allow for a local symlink
attack. When writing the PID file Unbound creates the file if it is not there,
or opens an existing file for writing. In case the file was already present, it
would follow symlinks if the file happened to be a symlink instead of a regular
file (CVE-2020-28935).

References:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-28935
https://www.debian.org/lts/security/2021/dla-2556
========================

Updated packages in core/updates_testing:
========================
unbound-1.10.1-1.1.mga7
libunbound8-1.10.1-1.1.mga7
libunbound-devel-1.10.1-1.1.mga7
python2-unbound-1.10.1-1.1.mga7
python3-unbound-1.10.1-1.1.mga7

from unbound-1.10.1-1.1.mga7.src.rpm

Thank you David for the update, and sorry, I've been quite busy lately and now read my all bugfix requests :-/

CC: (none) => eatdirt

MGA7-64 MATE on PeaqC1011
No installation issues
Ref bug 26646 Comment 3
# systemctl  start unbound

# systemctl -l status unbound
● unbound.service - Unbound DNS Resolver
   Loaded: loaded (/usr/lib/systemd/system/unbound.service; disabled; vendor preset: disabled)
   Active: active (running) since Tue 2021-03-23 11:15:47 CET; 14s ago
 Main PID: 31354 (unbound)
    Tasks: 1 (limit: 2285)
   Memory: 7.4M
   CGroup: /system.slice/unbound.service
           └─31354 /usr/sbin/unbound -c /etc/unbound/unbound.conf

Mar 23 11:15:47 mach7.hviaene.thuis systemd[1]: Started Unbound DNS Resolver.
Mar 23 11:15:47 mach7.hviaene.thuis unbound[31354]: [31354:0] notice: init module 0: validator
Mar 23 11:15:47 mach7.hviaene.thuis unbound[31354]: [31354:0] notice: init module 1: iterator
Mar 23 11:15:47 mach7.hviaene.thuis unbound[31354]: [31354:0] info: start of service (unbound 1.10.1).
 OK

CC: (none) => herman.viaene
Whiteboard: (none) => MGA7-64-OK

Validating. Advisory in Comment 2.

Keywords: (none) => validated_update
CC: (none) => andrewsfarm, sysadmin-bugs

An update for this issue has been pushed to the Mageia Updates repository.

https://advisories.mageia.org/MGASA-2021-0154.html

Status: NEW => RESOLVED
Resolution: (none) => FIXED

Hi,
Is it possible to preserve the systemd unit file when updating this RPM (also in Mga8)?
In your .spec : %config(noreplace) for /lib/systemd/system/unbound.service

CC: (none) => richard

I am not really in favour of this but I do not know our policy about systemd configuration files.

However, if there is a bug in it, you should open an independent bug report and I'll be happy to fix it of course!

(In reply to rexy from comment #7)
> Hi,
> Is it possible to preserve the systemd unit file when updating this RPM
> (also in Mga8)?
> In your .spec : %config(noreplace) for /lib/systemd/system/unbound.service

All that is in /lib/systemd/system should always have best default values, generally according to upstream documentation.

But /etc/systemd/system/unbound.service MUST contain YOuR personalization, your own settings and always takes leadership over the unit in /lib/systemd/system.

So no, we CAN'T have in our .spec : %config(noreplace) for /lib/systemd/system/unbound.service

It is how systemd runs. Defaults best settings and if any, newer, in /lib/systemd/system ; and YOUR modifications in /etc/systemd/system.

You can also put a .conf file in /etc/systemd/system/unbound.service.d/ to override parts of the service file, rather than the whole thing.

Ok thank's a lot for these clear explanations about systemd custom files.