In data martedì 7 dicembre 2021 11:23:07 CET, Stakanov ha scritto:

In data martedì 7 dicembre 2021 10:44:28 CET, Carlos E. R. ha scritto:

...

On Tuesday, 2021-12-07 at 09:57 +0100, Stakanov wrote:

...

Unbound cannot start because of an apparent permission issue.

Output is: × unbound.service - Unbound recursive Domain Name Server

Loaded: loaded (/usr/lib/systemd/system/unbound.service; enabled; vendor preset: disabled)

Active: failed (Result: exit-code) since

...

...

Tue 2021-12-07 08:14:54 CET; 1h 25min ago>

Process: 1937 ExecStartPre=/usr/bin/sudo -u unbound /usr/sbin/unbound-

Now this is peculiar. A service using sudo to start? Perhaps the service is not running as root.

...

Process: 1994 ExecStart=/usr/sbin/unbound -d $UNBOUND_OPTIONS (code=exited, status=1/FAILURE)

Main PID: 1994 (code=exited, status=1/FAILURE)

Then this process (1994) would not be running as root. And it fails:

...

Dec 07 08:14:54 silversurfer unbound[1994]: [1638861294] unbound[1994:0] error: Could not open /etc/unbound/unbound.conf: Permission denied

...

...

entropy@silversurfer:~> ls -l /etc/unbound/ totale 24 drwxr-xr-x 1 root unbound 32 7 dic 09.53 conf.d drwxr-xr-x 1 root unbound 30 7 dic 09.53 keys.d drwxr-xr-x 1 root unbound 44 7 dic 09.53 local.d -rw-r----- 1 root unbound 21947 22 apr 2018 unbound.conf

If the process is not running as root, it can not read unbound.conf.

-- Cheers,

Carlos E. R. (from openSUSE 15.2 x86_64 at Telcontar)

but for what I understood the service is intentional not running as root. And this for what I understand for security reasons? The thing about the permission is haunting me since quite a while. You can of course relax the permissions for unbound conf but I do not know if this is a bug or if this is a setup error that I am making. and forget about sudo, I did run it from CLI as root but it fails either way

silversurfer:~ # unbound -d [1638872635] unbound[22176:0] error: Could not open /etc/unbound/unbound.conf: Permission denied [1638872635] unbound[22176:0] fatal error: Could not read config file: /etc/ unbound/unbound.conf. Maybe try unbound -dd, it stays on the commandline to see more errors, or unbound-checkconf

In data martedì 7 dicembre 2021 21:44:19 CET, Mark Petersen ha scritto:

December 7, 2021 2:57 AM, "Stakanov" wrote:

...

Unbound cannot start because of an apparent permission issue.

Output is: × unbound.service - Unbound recursive Domain Name Server Loaded: loaded (/usr/lib/systemd/system/unbound.service; enabled; vendor preset: disabled) Active: failed (Result: exit-code) since Tue 2021-12-07 08:14:54 CET; 1h 25min ago Process: 1937 ExecStartPre=/usr/bin/sudo -u unbound /usr/sbin/unbound- anchor -a /var/lib/unbound/root.key -c /etc/unbound/icannbundle.pem (code=exited, status=0/SUCCESS) Process: 1993 ExecStartPre=/usr/sbin/unbound-checkconf (code=exited, status=0/SUCCESS) Process: 1994 ExecStart=/usr/sbin/unbound -d $UNBOUND_OPTIONS (code=exited, status=1/FAILURE) Main PID: 1994 (code=exited, status=1/FAILURE) CPU: 25ms

Dec 07 08:14:54 silversurfer sudo[1937]: pam_kwallet5(sudo:session): pam_kwallet5: pam_sm_close_session Dec 07 08:14:54 silversurfer sudo[1937]: pam_kwallet5(sudo:setcred): pam_kwallet5: pam_sm_setcred Dec 07 08:14:54 silversurfer unbound-checkconf[1993]: [1638861294] unbound- checkconf[1993:0] warning: Explicit port randomisation disabled, ignoring outgoing-port-permit and outgoing-port-avoid configuration options Dec 07 08:14:54 silversurfer unbound-checkconf[1993]: [1638861294] unbound- checkconf[1993:0] warning: Explicit port randomisation disabled, ignoring outgoing-port-permit and outgoing-port-avoid configuration options Dec 07 08:14:54 silversurfer unbound-checkconf[1993]: unbound-checkconf: no errors in /etc/unbound/unbound.conf Dec 07 08:14:54 silversurfer systemd[1]: Started Unbound recursive Domain Name Server. Dec 07 08:14:54 silversurfer unbound[1994]: [1638861294] unbound[1994:0] error: Could not open /etc/unbound/unbound.conf: Permission denied Dec 07 08:14:54 silversurfer unbound[1994]: [1638861294] unbound[1994:0] fatal error: Could not read config file: /etc/unbound/unbound.conf. Maybe try unbound -dd, it stays on the commandline to see more errors, or unbound- checkconf Dec 07 08:14:54 silversurfer systemd[1]: unbound.service: Main process exited, code=exited, status=1/FAILURE Dec 07 08:14:54 silversurfer systemd[1]: unbound.service: Failed with result 'exit-code'.

So the event is here:

...

Process: 1994 ExecStart=/usr/sbin/unbound -d $UNBOUND_OPTIONS (code=exited, status=1/FAILURE)

And it seems to be a permission issue:

...

Dec 07 08:14:54 silversurfer unbound[1994]: [1638861294] unbound[1994:0] error: Could not open /etc/unbound/unbound.conf: Permission denied Dec 07 08:14:54 silversurfer unbound[1994]: [1638861294] unbound[1994:0] fatal error: Could not read config file: /etc/unbound/unbound.conf. Maybe try unbound -dd, it stays on the commandline to see more errors, or unbound-checkconf

running unbound with -dd as sudo on CLI gives no further hints, same output.

So, is this a packaging issue / pam issue that should be reported? Do the users have all to be part of the unbound group? (Would make any sense to me). Or do I have to put explicitly root to user of the unbound group?

Permission of /etc/unbound/unbound.conf are (default, I erased my own setup and de and then reinstalled the package) as follows: entropy@silversurfer:~> ls -l /etc/unbound/ totale 24 drwxr-xr-x 1 root unbound 32 7 dic 09.53 conf.d drwxr-xr-x 1 root unbound 30 7 dic 09.53 keys.d drwxr-xr-x 1 root unbound 44 7 dic 09.53 local.d -rw-r----- 1 root unbound 21947 22 apr 2018 unbound.conf

should unbound.conf be readable to unbound user? What is wrong here. Any help appreciated.

Unbound is running fine on my Tumbleweed install:

cloud2:~ # systemctl status unbound ● unbound.service - Unbound recursive Domain Name Server Loaded: loaded (/usr/lib/systemd/system/unbound.service; enabled; vendor preset: disabled) Active: active (running) since Fri 2021-12-03 12:25:40 CST; 4 days ago Process: 2010 ExecStartPre=/usr/bin/sudo -u unbound /usr/sbin/unbound-anchor -a /var/lib/unbound/root.key -c /etc/unbound/icannbundle.pem (code=exited, status=0/SUCCESS) Process: 2169 ExecStartPre=/usr/sbin/unbound-checkconf (code=exited, status=0/SUCCESS) Main PID: 2175 (unbound) Tasks: 2 (limit: 2332) CPU: 358ms CGroup: /system.slice/unbound.service └─2175 /usr/sbin/unbound -d

Dec 03 12:25:41 cloud2 unbound[2175]: [1638555941] unbound[2175:0] warning: Explicit port randomisation disabled, ignoring outgoing-port-permit and outgoing-port-avoid configuration options Dec 03 12:25:41 cloud2 unbound[2175]: [2175:0] notice: init module 0: validator Dec 03 12:25:41 cloud2 unbound[2175]: [2175:0] notice: init module 1: iterator Dec 03 12:25:41 cloud2 unbound[2175]: [2175:0] info: start of service (unbound 1.13.2). Dec 03 23:17:53 cloud2 unbound[2175]: [2175:0] info: generate keytag query _ta-4f66. NULL IN Dec 04 10:09:56 cloud2 unbound[2175]: [2175:0] info: generate keytag query _ta-4f66. NULL IN Dec 04 22:05:31 cloud2 unbound[2175]: [2175:0] info: generate keytag query _ta-4f66. NULL IN Dec 05 20:40:08 cloud2 unbound[2175]: [2175:0] info: generate keytag query _ta-4f66. NULL IN Dec 06 08:21:58 cloud2 unbound[2175]: [2175:0] info: generate keytag query _ta-4f66. NULL IN Dec 07 06:33:33 cloud2 unbound[2175]: [2175:0] info: generate keytag query _ta-4f66. NULL IN

cloud2:~ # ll /var/lib/unbound/ total 4 -rw-r--r-- 1 unbound unbound 759 Dec 7 06:33 root.key

cloud2:~ # ll /etc/unbound/ total 56 drwxr-xr-x 1 root unbound 32 Oct 24 16:57 conf.d -rw-r--r-- 1 root unbound 493 Oct 19 18:13 dlv.isc.org.key -rw-r--r-- 1 root root 4358 Oct 16 2018 icannbundle.pem drwxr-xr-x 1 root unbound 30 Oct 24 16:57 keys.d drwxr-xr-x 1 root unbound 44 Oct 24 16:57 local.d -rw-r--r-- 1 root unbound 653 Oct 19 18:13 root.key -rw-r----- 1 root unbound 21947 Apr 22 2018 unbound.conf -rw-r----- 1 root unbound 2459 Nov 27 2019 unbound_control.key -rw-r----- 1 root unbound 1342 Nov 27 2019 unbound_control.pem -rw-r----- 1 root unbound 2459 Nov 27 2019 unbound_server.key -rw-r----- 1 root unbound 1334 Nov 27 2019 unbound_server.pem

cloud2:~ # zypper info unbound

Loading repository data... Reading installed packages...

Information for package unbound: -------------------------------- Repository : repo-oss Name : unbound Version : 1.13.2-2.1 Arch : x86_64 Vendor : openSUSE Installed Size : 3.1 MiB Installed : Yes Status : up-to-date Source package : unbound-1.13.2-2.1.src Summary : Validating, recursive, and caching DNS(SEC) resolver

Could you have an issue with apparmor or do you have another DNS resolver running which would prevent unbound from binding to port 53?

Mark I excluded any other dns(sec) resolver. I then tried also to check apparmor but there is not profile on unbound so it is not active. The problem persistet. When I change selectively unbound.conf to unbound:unbound the permission problem is gone.

In data giovedì 9 dicembre 2021 22:17:53 CET, Christian Boltz ha scritto:

Wild guess: can you check if the unbound user is a member of the unbound group? I'd expect something like (uid and gid might differ)

This is correct. Output is: uid=490(unbound) gid=477(unbound) groups=477(unbound)

On 10/12/2021 08.21, Stakanov wrote:

...

...

Wild guess: can you check if the unbound user is a member of the unbound group? I'd expect something like (uid and gid might differ)

This is correct. Output is: uid=490(unbound) gid=477(unbound) groups=477(unbound)

As well, this morning, even if the permissions are right now, still I get a failure to start with:

...

dic 10 08:14:47 localhost unbound[1613]: [1639120487] unbound[1613:0] error: Could not open /etc/unbound/unbound.conf: Permission denied dic 10 08:14:47 localhost unbound[1613]: [1639120487] unbound[1613:0] fatal error: Could not read config file: /etc/unbound/unbound.conf. Maybe try unbound -dd, it stays on the commandline to see more errors, or unbound-chec> dic 10 08:14:47 localhost systemd[1]: unbound.service: Main process exited, code=exited, status=1/FAILURE dic 10 08:14:47 localhost systemd[1]: unbound.service: Failed with result 'exit-code'.

Is it possible that apparmor does interfere even if no profile is existing for unbound (and when checking no profile of this kind is active)?

No.

I do not really understand why it should not be possible for the program to claim a permission issue.

Check the current permissions of /etc/unbound/unbound.conf -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)

It was actually a former unbound AA profile (which for a reason I do not understand was on enforce while I would have expected remaining profiles from previous installation would be on complain. Well, what can I say: now even leaving the original permissions it works. I do not know if the programmer of the yast interface will ever read this, but my impression is, that the little tick box "show inactive profiles" could be a bit more prominent. Maybe it is my lack of observation but I did not notice it and simply searched for active profiles, while the profile that made trouble had already returned to inactive ones. Someone has the temptation to consider "unused profiles" as not used at all, and not that they may have interfered already in the current session, with blocking something.

In data venerdì 10 dicembre 2021 17:12:28 CET, Mark Petersen ha scritto:

aa-logprof is what I use to see if apparmor is blocking something.

Would this give a positive feedback even after the service aborted? Or do one use it parallel like a kind of log during execution of the service and it gives the output after the service shuts down? Thank you.

Hello, Am Samstag, 11. Dezember 2021, 11:25:40 CET schrieb Carlos E. R.:

Telcontar:~ # aa-logprof Reading log entries from /var/log/audit/audit.log. Updating AppArmor profiles in /etc/apparmor.d. Enforce-mode changes:

Profile: /usr/sbin/dnsmasq Path: /proc/2806/fd/ New Mode: owner r [...] Ah, I pressed "A" for "Allow", not "Owner". No idea what means that "owner".

The "owner" prefix makes the rule more strict, so that only programs running as the user who owns the file are allowed to access that file. For example, let's say you have a profile for vim which has owner /home/*/.vimrc r, and you have # ls -l /home/*/.vimrc -rw-r--r-- 1 cb users 5210 7. Apr 2021 /home/cb/.vimrc -rw-r--r-- 1 carlos users 1234 2. Apr 2019 /home/carlos/.vimrc that would mean that (based on the file permissions) all users can read the .vimrc files, and user "cb" could cat /home/carlos/.vimrc Now if your vim runs under AppArmor confinement and user "cb" starts vim, only /home/cb/.vimrc can be read. Access to /home/carlos/.vimrc will be denied thanks to the "owner" restriction. Regards, Christian Boltz --

...

Wozu braucht man dann die Blockchain? Dafür wofür man die Blockchain immer braucht... Fürs Bullshitbingo? [https://twitter.com/KapikHusky/status/1305850130583695361]