Problem with pidfile and permission...

Unbound
1

Hi folks,

i’ve installed Unbound from source in another folder, set the unbound.conf and try to start it.

But the start failed with “cannot open pidfile /test/unbound/unbound.pid : Permission denied”.

The error only comes when i try to start unbound with “sudo systemctl start unbound”.

If i cd to “/test/unbound” and start with “sudo sbin/unbound -d -vvvv”, then all works.

The installation folder is owned by the user “test_unbound” and the content of unbound.conf is:

2

Hi folks,

i've installed Unbound from source in another folder, set the unbound.conf and try
to start it.
But the start failed with "cannot open pidfile /test/unbound/unbound.pid :
Permission denied".

is it enough to:

% cd /test/unbound
% sudo chown -Rh unbound:unbound .

Then try to start it again?

FWIW all the systems I run that create pidfiles, either put them in

/var/run

or

/tmp

3

Hi folks,
i've installed Unbound from source in another folder, set the unbound.conf and try
to start it.
But the start failed with "cannot open pidfile /test/unbound/unbound.pid :
Permission denied".

is it enough to:

% cd /test/unbound
% sudo chown -Rh unbound:unbound .

Then try to start it again?

FWIW all the systems I run that create pidfiles, either put them in

/var/run

or

/tmp

Yes and likely SElinux would fail outside of those directories.

I using systemd, it would be better to use a type=simple without pidfile.

Paul

4

Thanks for your answers.

is it enough to:

% cd /test/unbound

% sudo chown -Rh unbound:unbound .

Then try to start it again?

Unfortunately no. Like i wrote in my question, the installation folder is already owned by the user “test_unbound” wich also set in the config.

FWIW all the systems I run that create pidfiles, either put them in

/var/run

or

/tmp

If i use this directories the error turns to “Read-only file system”.

I already thought, that the permission-error is not a “real” permission thing, but a specific option in the service-file which is unlikely causing the restriction.

That also confirms by the fact that if i manually start with “sudo sbin/unbound -d -vvvv” the output is:

5

Thanks for your answers.

You're welcome. :slight_smile:

is it enough to:

% cd /test/unbound
% sudo chown -Rh unbound:unbound .

Then try to start it again?

Unfortunately no. Like i wrote in my question, the installation folder is already
owned by the user "test_unbound" wich also set in the config.

FWIW all the systems I run that create pidfiles, either put them in

/var/run

or

/tmp

If i use this directories the error turns to "Read-only file system".
I already thought, that the permission-error is not a "real" permission thing, but
a specific option in the service-file which is unlikely causing the restriction.

That also confirms by the fact that if i manually start with "sudo sbin/unbound -d
-vvvv" the output is:

===================================
[1641309759] unbound[10544:0] notice: Start of unbound 1.14.0.
[1641309759] unbound[10544:0] debug: creating udp4 socket 127.0.0.1 53
[1641309759] unbound[10544:0] debug: creating tcp4 socket 127.0.0.1 53
[1641309759] unbound[10544:0] debug: creating udp4 socket 127.0.0.1 53
[1641309759] unbound[10544:0] debug: creating tcp4 socket 127.0.0.1 53
[1641309759] unbound[10544:0] debug: creating udp4 socket 127.0.0.1 53
[1641309759] unbound[10544:0] debug: creating tcp4 socket 127.0.0.1 53
[1641309759] unbound[10544:0] debug: creating udp4 socket 127.0.0.1 53
[1641309759] unbound[10544:0] debug: creating tcp4 socket 127.0.0.1 53
[1641309759] unbound[10544:0] debug: chdir to /test/unbound
[1641309759] unbound[10544:0] debug: chroot to /test/unbound
[1641309759] unbound[10544:0] debug: drop user privileges, run as test_unbound
[1641309759] unbound[10544:0] debug: switching log to /test/unbound/log.log

while the output (systemctl status unbound) from the start via the service-file is:

===================================
Jan 04 16:23:42 dimitri unbound[10556]: [1641309822] unbound[10556:0] debug:
creating tcp4 socket 127.0.0.1 53
Jan 04 16:23:42 dimitri unbound[10556]: [1641309822] unbound[10556:0] debug:
creating udp4 socket 127.0.0.1 53
Jan 04 16:23:42 dimitri unbound[10556]: [1641309822] unbound[10556:0] debug:
creating tcp4 socket 127.0.0.1 53
Jan 04 16:23:42 dimitri unbound[10556]: [1641309822] unbound[10556:0] debug:
creating udp4 socket 127.0.0.1 53
Jan 04 16:23:42 dimitri unbound[10556]: [1641309822] unbound[10556:0] debug:
creating tcp4 socket 127.0.0.1 53
Jan 04 16:23:42 dimitri unbound[10556]: [1641309822] unbound[10556:0] error:
cannot open pidfile /test/unbound/unbound.pid: Permission denied
Jan 04 16:23:42 dimitri unbound[10556]: [1641309822] unbound[10556:0] debug: chdir
to /test/unbound

I'm going out on a limb here, as I'm running unbound on *BSD systems. But after you
encounter the failure here. What permissions does /test/unbound/ && /test/ have?
IOW does the unbound user own them? Is /test/unbound/unbound.pid owned by the
unbound user? The answer to these questions should help you narrow the systemd
setup. Last, but not least (I know this may sound stupid) the unbound user was
created, right? Has the necessary perms? Sorry. Just trying to cover all the
bases. :slight_smile:

Good luck! :slight_smile:

-- Chris

6

Hi,
do you use apparmor? if yes check the paths in the apparmor unbound profile file.

Ciao,
Tito

7

Hi Chris

What permissions does /test/unbound/ && /test/ have?

Directorie /test and subs all owned by the user “test_unbound”

IOW does the unbound user own them?

No, i don’t using the standard “unbound” user. I use “test_unbound” which i of course set in the config.

Is /test/unbound/unbound.pid owned by the unbound user?

The pidfile only exists on runtime when Unbound at startup creates it.

When i manually start unbound, it creates the pidfile correct owned by the user “test_unbound”.

And yes, the user “test_unbound” exists :wink:

Like i said, this doesn’t seems like a “real” permission problem because (as the output says) unbound drops the privileges only

after chdir and chroot and the error comes before chdir in the output.

So i think that unbound creates the pidfile as root and then changed the owner.

8

Hi Jarno

You have lot of sandboxing options(Protect*, Restrict* etc.) in the

unbound.service file.

Have you tried commenting all Protect*, Restrict* etc. and see if

unbound is then able to start (and write to /test/unbound) ? And after that start

adding those sandboxing options one by one ?

Yes, it was my next step yesterday.

And i find out that if i set a plus as the first character on “ExecStart=…” (which means execution with full privileges)

then the no pidfile-error occurs.

I would like to know why because i thougt that if no “User=” option in the service is set, then the service automaticly starts as root.

But the pidfile-error was not responsible for the failed start, it was the following line in my service-file:

9

Hi folks,

finally i found the problem why Type=notify in my service-file leads to the timeout error.

I’ve just seen that i’ve forgotten to set the “–enable-systemd” to the configuration options before compiling unbound.

Now it works as it should.

However thanks to all who wrote and nice weekend :wink: