19 Dub
2018
19 Dub
'18
11:24
Hi,
I have a fresh installation of the Knot Resolver on my Fedora 27:
*Package version*:
$ rpm -q knot-resolver
knot-resolver-2.2.0-1.fc27.x86_64
but it does not work out of the box. The problem is, that the user
"knot-resolver" cannot bind to a privileged port. Why is the systemd
service file using knot-resolver user? It works just fine, when I remove
the "User=" option from service file and add this line into the
kres.conf file:
user('knot-resolver', 'knot-resolver')
The resulting process runs as knot-resolver and it binds successfully.
Best regards,
--
Martin Sehnoutka | Associate Software Engineer
PGP: 5FD64AF5
UTC+1 (CET)
RED HAT | TRIED. TESTED. TRUSTED.
19 Dub
19 Dub
12:19
Hi!
On 2018-04-19 11:24, Martin Sehnoutka wrote:> I have a fresh
installation of the Knot Resolver on my Fedora 27
but it does not work out of the box.
Short answer:
$ dnf update selinux-policy
The problem is, that the user
"knot-resolver" cannot bind to a privileged port. Why is the systemd
service file using knot-resolver user? It works just fine, when I remove
the "User=" option from service file and add this line into the
kres.conf file:
user('knot-resolver', 'knot-resolver')
Long answer:
The kresd service isn't supposed to bind to any port. Instead, this is
handled by systemd, which passes kresd.socket to the kresd service. The
purpose of this is to reduce the attack surface of the service by
reducing its privileges to the absolute necessities.
However, there were bugs in selinux-policy [bz1366968, bz1543049] which
prevented the proper creation of the socket by systemd. When systemd
fails to provide kresd with a socket, the service falls back to attempt
to bind to a port, which fails, because it doesn't have the needed
privileges. That's why you see these messages in the log.
I've encountered this issue before and the log messages are quite
misleading and don't help to debug the cause of the problem at all. I
think this is something we should fix, so I've opened an issue [#342]
for it.
bz1366968 - https://bugzilla.redhat.com/show_bug.cgi?id=1366968
bz1543049 - https://bugzilla.redhat.com/show_bug.cgi?id=1543049
#342 - https://gitlab.labs.nic.cz/knot/knot-resolver/issues/342
--
Tomas Krizek
PGP: 4A8B A48C 2AED 933B D495 C509 A1FB A5F7 EF8C 4869
13:19
On 04/19/2018 12:19 PM, Tomas Krizek wrote:
--
Martin Sehnoutka | Associate Software Engineer
PGP: 5FD64AF5
UTC+1 (CET)
RED HAT | TRIED. TESTED. TRUSTED.
Hi!
On 2018-04-19 11:24, Martin Sehnoutka wrote:> I have a fresh
installation of the Knot Resolver on my Fedora 27
It is still in testing. Anyway I tried to turn off SELinux, but the
result was the same. Isn't it supposed to work in that case?
Anyway thanks for your prompt response!
but it does not work out of the box.
Short answer:
$ dnf update selinux-policy The problem is, that the user
"knot-resolver" cannot bind to a privileged port. Why is the systemd
service file using knot-resolver user? It works just fine, when I remove
the "User=" option from service file and add this line into the
kres.conf file:
user('knot-resolver', 'knot-resolver')
Long answer:
The kresd service isn't supposed to bind to any port. Instead, this is
handled by systemd, which passes kresd.socket to the kresd service. The
purpose of this is to reduce the attack surface of the service by
reducing its privileges to the absolute necessities.
However, there were bugs in selinux-policy [bz1366968, bz1543049] which
prevented the proper creation of the socket by systemd. When systemd
fails to provide kresd with a socket, the service falls back to attempt
to bind to a port, which fails, because it doesn't have the needed
privileges. That's why you see these messages in the log.
I've encountered this issue before and the log messages are quite
misleading and don't help to debug the cause of the problem at all. I
think this is something we should fix, so I've opened an issue [#342]
for it.
bz1366968 - https://bugzilla.redhat.com/show_bug.cgi?id=1366968
bz1543049 - https://bugzilla.redhat.com/show_bug.cgi?id=1543049
#342 - https://gitlab.labs.nic.cz/knot/knot-resolver/issues/342
15:46
On 2018-04-19 13:19, Martin Sehnoutka wrote:
On 04/19/2018 12:19 PM, Tomas Krizek wrote:
The bugs have been fixed in selinux-policy-3.13.1-283.26.fc27. Even
newer version of selinux-policy is available from F27 updates repo.
It is inadvisable to turn off SELinux, but it does work even with the
old selinux-policy when you issue `getenforce 0` and start the service.
I've tested this on a clean VM with out of the box installation of
knot-resolver.
--
Tomas Krizek
PGP: 4A8B A48C 2AED 933B D495 C509 A1FB A5F7 EF8C 4869
$ dnf update selinux-policy
It is still in testing. Anyway I tried to turn off SELinux, but the
result was the same. Isn't it supposed to work in that case?
2439
days inactive
2439
days old
knot-resolver-users@lists.nic.cz
3 comments
2 participants
participants (2)
-
Martin Sehnoutka -
Tomas Krizek