12 Čen
2012
12 Čen
'12
20:39
Hello,
Yesterday I replaced one of my authoritative servers with knot 1.0.5
(previously powerdns). I am already delighted by the simplicity of knot,
so thank you for a nice piece of software.
I tried some configurations and noticed that I was unable to correctly
run as an unprivileged user. It seems that the problem is:
- start knotd as root.root
- create empty pidfile (owned by root.root)
- drop privileges to user 'knot.knot'
- write pid to pidfile (and fail doing so)
- log error:
2012-06-11T22:23:06+02:00 julie knot[31184]: [warning] Failed to create
PID file '/var/lib/knot/knot.pid'.
2012-06-11T22:23:06+02:00 julie knot[31184]: Server started as a daemon,
PID = 31184
2012-06-11T22:23:06+02:00 julie knot[31184]: [warning] Server running
without PID file.
When stopping knotd later on, the following is logged, and knotd does
not stop running.
2012-06-11T22:23:38+02:00 julie knot[31210]: [warning] Server PID not
found, probably not running.
I guess that either the pid file need to be chowned to the unprivileged
user before privileges are dropped, or the pid needs to be written to
the file earlier. Note that the file *is* created (despite the error
messages saying something else), but it is empty.
Kind regards,
Tom
14 Čen
14 Čen
19:45
Hi,
first - thanks for giving Knot DNS a shot, really appreciated. I have
reproduced the issue and created a ticket
https://git.nic.cz/redmine/issues/1909 to track it. I'm going to
tackle it tomorrow (hopefully).
I can send you a patch against 1.0.5 if you're interested, or you can
wait and it will be present in the next release.
Cheers,
Marek
On 12 June 2012 20:39, Tom Hendrikx <tom(a)whyscream.net> wrote:
Hello,
Yesterday I replaced one of my authoritative servers with knot 1.0.5
(previously powerdns). I am already delighted by the simplicity of knot,
so thank you for a nice piece of software.
I tried some configurations and noticed that I was unable to correctly
run as an unprivileged user. It seems that the problem is:
- start knotd as root.root
- create empty pidfile (owned by root.root)
- drop privileges to user 'knot.knot'
- write pid to pidfile (and fail doing so)
- log error:
2012-06-11T22:23:06+02:00 julie knot[31184]: [warning] Failed to create
PID file '/var/lib/knot/knot.pid'.
2012-06-11T22:23:06+02:00 julie knot[31184]: Server started as a daemon,
PID = 31184
2012-06-11T22:23:06+02:00 julie knot[31184]: [warning] Server running
without PID file.
When stopping knotd later on, the following is logged, and knotd does
not stop running.
2012-06-11T22:23:38+02:00 julie knot[31210]: [warning] Server PID not
found, probably not running.
I guess that either the pid file need to be chowned to the unprivileged
user before privileges are dropped, or the pid needs to be written to
the file earlier. Note that the file *is* created (despite the error
messages saying something else), but it is empty.
Kind regards,
Tom
_______________________________________________
knot-dns-users mailing list
knot-dns-users(a)lists.nic.cz
https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users
17 Čen
17 Čen
18:03
Hi Marek,
I already updated to 1.0.6, so you could provide the patch against that
(or simply git), but I'm willing to test the fix when it's ready.
Regards,
Tom
On 14-06-12 19:45, Marek Vavruša wrote:
Hi,
first - thanks for giving Knot DNS a shot, really appreciated. I have
reproduced the issue and created a ticket
https://git.nic.cz/redmine/issues/1909 to track it. I'm going to
tackle it tomorrow (hopefully).
I can send you a patch against 1.0.5 if you're interested, or you can
wait and it will be present in the next release.
Cheers,
Marek
On 12 June 2012 20:39, Tom Hendrikx <tom(a)whyscream.net> wrote:
Hello,
Yesterday I replaced one of my authoritative servers with knot 1.0.5
(previously powerdns). I am already delighted by the simplicity of knot,
so thank you for a nice piece of software.
I tried some configurations and noticed that I was unable to correctly
run as an unprivileged user. It seems that the problem is:
- start knotd as root.root
- create empty pidfile (owned by root.root)
- drop privileges to user 'knot.knot'
- write pid to pidfile (and fail doing so)
- log error:
2012-06-11T22:23:06+02:00 julie knot[31184]: [warning] Failed to create
PID file '/var/lib/knot/knot.pid'.
2012-06-11T22:23:06+02:00 julie knot[31184]: Server started as a daemon,
PID = 31184
2012-06-11T22:23:06+02:00 julie knot[31184]: [warning] Server running
without PID file.
When stopping knotd later on, the following is logged, and knotd does
not stop running.
2012-06-11T22:23:38+02:00 julie knot[31210]: [warning] Server PID not
found, probably not running.
I guess that either the pid file need to be chowned to the unprivileged
user before privileges are dropped, or the pid needs to be written to
the file earlier. Note that the file *is* created (despite the error
messages saying something else), but it is empty.
Kind regards,
Tom
_______________________________________________
knot-dns-users mailing list
knot-dns-users(a)lists.nic.cz
https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users
_______________________________________________
knot-dns-users mailing list
knot-dns-users(a)lists.nic.cz
https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users
20 Čen
20 Čen
18:58
Hi Tom,
so I have finally addressed the issue. Well, here are the changes:
- uid/gid is now changed only after startup (instead of each
configuration reload)
- PID file and others are created under correct configured user
(config key 'user myuser.mygroup')
- knotc now respects configuration (so zones are compiled under configured user)
- corrected log messages to be more helpful
- knotd now checks if 'storage' is writable and let's you know if it
isn't
So to run knotd as 'knot.knot' you have to make sure that the
'storage' directory exists and is writable by that user (
'/var/lib/knot' in your case). You can change 'storage' or
'pidfile'
path in the config, but still have to make sure the 'knot.knot' can
write to those. This should work even without the patch, so give it a
shot and let me know.
Kind regards,
Marek
On 17 June 2012 18:03, Tom Hendrikx <tom(a)whyscream.net> wrote:
Hi Marek,
I already updated to 1.0.6, so you could provide the patch against that
(or simply git), but I'm willing to test the fix when it's ready.
Regards,
Tom
On 14-06-12 19:45, Marek Vavruša wrote:
Hi,
first - thanks for giving Knot DNS a shot, really appreciated. I have
reproduced the issue and created a ticket
https://git.nic.cz/redmine/issues/1909 to track it. I'm going to
tackle it tomorrow (hopefully).
I can send you a patch against 1.0.5 if you're interested, or you can
wait and it will be present in the next release.
Cheers,
Marek
On 12 June 2012 20:39, Tom Hendrikx <tom(a)whyscream.net> wrote:
_______________________________________________
knot-dns-users mailing list
knot-dns-users(a)lists.nic.cz
https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users Hello,
Yesterday I replaced one of my authoritative servers with knot 1.0.5
(previously powerdns). I am already delighted by the simplicity of knot,
so thank you for a nice piece of software.
I tried some configurations and noticed that I was unable to correctly
run as an unprivileged user. It seems that the problem is:
- start knotd as root.root
- create empty pidfile (owned by root.root)
- drop privileges to user 'knot.knot'
- write pid to pidfile (and fail doing so)
- log error:
2012-06-11T22:23:06+02:00 julie knot[31184]: [warning] Failed to create
PID file '/var/lib/knot/knot.pid'.
2012-06-11T22:23:06+02:00 julie knot[31184]: Server started as a daemon,
PID = 31184
2012-06-11T22:23:06+02:00 julie knot[31184]: [warning] Server running
without PID file.
When stopping knotd later on, the following is logged, and knotd does
not stop running.
2012-06-11T22:23:38+02:00 julie knot[31210]: [warning] Server PID not
found, probably not running.
I guess that either the pid file need to be chowned to the unprivileged
user before privileges are dropped, or the pid needs to be written to
the file earlier. Note that the file *is* created (despite the error
messages saying something else), but it is empty.
Kind regards,
Tom
_______________________________________________
knot-dns-users mailing list
knot-dns-users(a)lists.nic.cz
https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users
_______________________________________________
knot-dns-users mailing list
knot-dns-users(a)lists.nic.cz
https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users
25 Čen
25 Čen
21:37
On 20-06-12 18:58, Marek Vavruša wrote:
Hi Tom,
so I have finally addressed the issue. Well, here are the changes:
- uid/gid is now changed only after startup (instead of each
configuration reload)
- PID file and others are created under correct configured user
(config key 'user myuser.mygroup')
- knotc now respects configuration (so zones are compiled under configured user)
- corrected log messages to be more helpful
- knotd now checks if 'storage' is writable and let's you know if it
isn't
So to run knotd as 'knot.knot' you have to make sure that the
'storage' directory exists and is writable by that user (
'/var/lib/knot' in your case). You can change 'storage' or
'pidfile'
path in the config, but still have to make sure the 'knot.knot' can
write to those. This should work even without the patch, so give it a
shot and let me know.
I just gave your patch some testing against 1.0.6, but it doesn't work
as expected. Main problem is that the unprivileged user cannot bind to
the privileged port (53). Reviewing the code, it looks like privileges
are dropped in the knotc utility, before starting the server process
itself.
I also tried with high port numbers (f.i. 5353) and that does works
without any issues.
--
Tom
28 Čen
28 Čen
19:27
On 25 June 2012 21:37, Tom Hendrikx <tom(a)whyscream.net> wrote:
On 20-06-12 18:58, Marek Vavruša wrote:
That's actually true, sorry for that, I have fixed that now, so only
zone compilation processes
ownership is modified. It's in a latest git, but again a patch against
1.0.6 is included (at least the main bits).
Or try the latest git branch 'development'.
Kind regards,
Marek
Hi Tom,
so I have finally addressed the issue. Well, here are the changes:
- uid/gid is now changed only after startup (instead of each
configuration reload)
- PID file and others are created under correct configured user
(config key 'user myuser.mygroup')
- knotc now respects configuration (so zones are compiled under configured user)
- corrected log messages to be more helpful
- knotd now checks if 'storage' is writable and let's you know if it
isn't
So to run knotd as 'knot.knot' you have to make sure that the
'storage' directory exists and is writable by that user (
'/var/lib/knot' in your case). You can change 'storage' or
'pidfile'
path in the config, but still have to make sure the 'knot.knot' can
write to those. This should work even without the patch, so give it a
shot and let me know.
I just gave your patch some testing against 1.0.6, but it doesn't work
as expected. Main problem is that the unprivileged user cannot bind to
the privileged port (53). Reviewing the code, it looks like privileges
are dropped in the knotc utility, before starting the server process
itself.
I also tried with high port numbers (f.i. 5353) and that does works
without any issues.
--
Tom
_______________________________________________
knot-dns-users mailing list
knot-dns-users(a)lists.nic.cz
https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users
5 Čec
5 Čec
13:14
On 6/28/12 7:27 PM, Marek Vavruša wrote:
On 25 June 2012 21:37, Tom Hendrikx
<tom(a)whyscream.net> wrote:
I have 1.0.6 running with this patch for a few days now, and am not
seeing any issues with it. Thanks, feel free to include in 1.0.7 :)
--
Tom
On 20-06-12 18:58, Marek Vavruša wrote:
That's actually true, sorry for that, I have fixed that now, so only
zone compilation processes
ownership is modified. It's in a latest git, but again a patch against
1.0.6 is included (at least the main bits).
Or try the latest git branch 'development'.
Hi Tom,
so I have finally addressed the issue. Well, here are the changes:
- uid/gid is now changed only after startup (instead of each
configuration reload)
- PID file and others are created under correct configured user
(config key 'user myuser.mygroup')
- knotc now respects configuration (so zones are compiled under configured user)
- corrected log messages to be more helpful
- knotd now checks if 'storage' is writable and let's you know if it
isn't
So to run knotd as 'knot.knot' you have to make sure that the
'storage' directory exists and is writable by that user (
'/var/lib/knot' in your case). You can change 'storage' or
'pidfile'
path in the config, but still have to make sure the 'knot.knot' can
write to those. This should work even without the patch, so give it a
shot and let me know.
I just gave your patch some testing against 1.0.6, but it doesn't work
as expected. Main problem is that the unprivileged user cannot bind to
the privileged port (53). Reviewing the code, it looks like privileges
are dropped in the knotc utility, before starting the server process
itself.
I also tried with high port numbers (f.i. 5353) and that does works
without any issues.
4514
days inactive
4537
days old
6 comments
2 participants
participants (2)
-
Marek Vavruša -
Tom Hendrikx