docker-bind
docker-bind copied to clipboard
ventz
Startup arguments
Hi Ventz,
A couple of questions/issues about your great docker container:
-
named is launched with the "-g" option from entrypoint.sh. The unfortunate thing about that is it means logging can't be enabled, since -g redirects all logging to stdout, and causes named to ignore other logging directives. I would really like to configure logging to a volume. Any change of changing it to -f? I can't see any way to override -g (other than rebullding).
-
In entrypoint.sh, you chmod -R 770 on the two volumes. That makes everything in the volumes executable, which doesn't seem write. Was it mean instead to just chmod, rather than "-R"?
thanks, Stuart
Hi Stuart - sorry for the delay, missed this notification somehow.
-
For logging - the "recommended" way for docker to log is to send to stdout, and for the users to choose the docker log driver that's most appropriate (see: https://docs.docker.com/config/containers/logging/configure/). This allows essentially for a lot of flexibility - you can pipe to syslog, fluentd, a file, etc. You can always override the entry point completely with --entrypoint and create your own.
-
For the chmod - that's a great question. I want to say there was a reason for it (something specifically around when using slaves or dynamic zones via slaves), but to be honest I cannot remember. For the folder it would make sense to have execute, but for the rest 644 seems more reasonable. Let me test it out and get back to you on this one.
I was just about to report the weird file mode described in the second bullet. @ventz, did you look into this further?
Both items also in #32 and #34
I think it would be a good idea to keep comments in config files, so everybody can tell why the config is that way...
I may be miss-understanding the problem, but here's my production version currently:
...
chown -R named:named /var/cache/bind
chmod -R 770 /var/cache/bind /var/run/named
chmod -R 750 /etc/bind
...
Here is what the production file system looks like:
/ # ls -alh /var/cache/ | grep bind
drwxrwx--- 2 named named 4.0K Apr 29 06:11 bind
/ # ls -alh /var/cache/bind
...
-rwxrwx--- 1 named named 940 Apr 29 13:52 hosted_SOME-ZONE-NAME
...
There was one use-case (depending if just dynamic, or dynamic+extensions) where the 7 bit (read-write-execute) was needed, versus just the 6 bit (read-write).
Just to make sure I am understanding @ffabreti @magnusbaeck @sgjohnston - are you saying it should be read-write and NOT execute?
Thanks.
I think having the directories 770 makes sense (at least if we need writing by owner and group), but my comment earlier was about the files - 770 makes no sense for a non-executable file (such as hosted_SOME-ZONE-NAME in the example), they should be (at most) 660.
Cheers for looking at this again.
On 29 Apr 2020, at 16:40, Ventz Petkov [email protected] wrote:
I may be miss-understanding the problem, but here's my production version currently:
... chown -R named:named /var/cache/bind chmod -R 770 /var/cache/bind /var/run/named chmod -R 750 /etc/bind ... Here is what the production file system looks like:
/ # ls -alh /var/cache/ | grep bind drwxrwx--- 2 named named 4.0K Apr 29 06:11 bind
/ # ls -alh /var/cache/bind ... -rwxrwx--- 1 named named 940 Apr 29 13:52 hosted_SOME-ZONE-NAME ... There was one use-case (depending if just dynamic, or dynamic+extensions) where the 7 bit (read-write-execute) was needed, versus just the 6 bit (read-write).
Just to make sure I am understanding @ffabreti https://github.com/ffabreti @magnusbaeck https://github.com/magnusbaeck @sgjohnston https://github.com/sgjohnston - are you saying it should be read-write and NOT execute?
Thanks.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ventz/docker-bind/issues/29#issuecomment-621293586, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA554GLKWWWFM5O5SKYAH2TRPBC7TANCNFSM4JOWJTNQ.
Ok, I think I completely miss-understood your original request. (Deleting the comment about the docker run --user, and leaving a note here about it so you are not confused in case you are following this via email).
I just made changes which I think should satisfy what you are asking. @sgjohnston @ffabreti @magnusbaeck, would you mind deleting your pulled dynamic data (including the dir and re-creating it) and running the container and making sure it re-generates it with the correct permission/everything else works? I pulled a few systems here and it seems like everything works, but just to make sure.
I also used the change to update the ROOT "hints" file (db.root) to the latest official one from InterNIC, since it was updated 4-29-2020
@sgjohnston @ffabreti @magnusbaeck The commit is: b2983bd
If it works, I'll tag it and replace the latest stable tag
Hi ventz,
I tried a clean pull, without using any volumes, and it is still not right for the file permissions. I see the default /etc/bind as
-rwxr-x--- 1 root named 103 Apr 30 03:06 README lrwxrwxrwx 1 root named 49 Apr 30 03:06 bind.keys -> ../../usr/share/dnssec-root/bind-dnssec-root.keys drwxr-x--- 2 root named 8 Apr 30 09:26 default-zones drwxr-x--- 4 root named 5 Apr 30 09:26 example-configs -rwxr-x--- 1 root named 525 Apr 30 03:06 named.conf -rwxr-x--- 1 root named 1835 Nov 21 10:47 named.conf.authoritative -rwxr-x--- 1 root named 588 Apr 30 03:06 named.conf.default-zones -rwxr-x--- 1 root named 1224 Apr 30 03:06 named.conf.local -rwxr-x--- 1 root named 3637 Apr 30 03:06 named.conf.options -rwxr-x--- 1 root named 3897 Nov 21 10:47 named.conf.recursive -rwxr-x--- 1 root named 1569 Apr 30 03:06 named.conf.rfc1918 -rwxr-x--- 1 root named 100 Apr 30 03:06 rndc.key
the issue is the non-directory files, they still have execute permission. It’s because of the line in /entrypoint.sh
chmod -R 750 /etc/bind
Why is that even needed?
sgjohnston
On 30 Apr 2020, at 04:03, Ventz Petkov [email protected] wrote:
Ok, I think I completely miss-understood your original request. (Deleting the comment about the docker run --user, and leaving a note here about it so you are not confused in case you are following this via email).
I just made changes which I think should satisfy what you are asking. @sgjohnston https://github.com/sgjohnston @ffabreti https://github.com/ffabreti @magnusbaeck https://github.com/magnusbaeck, would you mind deleting your pulled dynamic data (including the dir and re-creating it) and running the container and making sure it re-generates it with the correct permission/everything else works? I pulled a few systems here and it seems like everything works, but just to make sure.
I also used the change to update the ROOT "hints" file (db.root) to the latest official one from InterNIC, since it was updated 4-29-2020
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ventz/docker-bind/issues/29#issuecomment-621584524, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA554GISFD5F6JJBTUV6ATTRPDS63ANCNFSM4JOWJTNQ.
@sgjohnston Thanks.
To your queston:
chmod -R 750 /etc/bind Why is that even needed?
Here is the background on this:
All of this started due to Bind ("named" service) having two main competing "standards" for where the "correct place to put things" is -- according to the official ISC2 released documentation. The problem is that some Linux distros implemented one and others implemented the other, while others implemented a hybrid in order to follow their own file/dir structure methodologies for configs vs "run-time" data vs "where service created things" live.
Looking at the main and still widely used systems - Debian vs Ubuntu vs RHEL vs CentOS vs AWS Linux vs OpenBSD vs Alpine have 3 different directory/permissions implementations between them, and 2 of those cannot co-exist on the same setup. To give you the complete list, in one they were in /etc/named, in another /etc/bind, in other they were in /var/named/cache or /var/cache/bind or /var/bind. I created this in 2014, on the first "non-alpha" Docker version and published it to Github in 2016 - at the time Alpine was not default for Docker containers, but the minimalism/size/security was attractive, and why I chose to go with Alpine.
I started following the more popular path/directory "standard" (Dynamic/bind-created live in /var/cache/bind) originally since it most widely adopted, and from what I can tell the semi-officially recognized one for everyone outside of RHEL/CentOS. Eventually someone brought up that the other competing "standard" should be supported for the users who want to use the file structure they are familiar with coming to Docker.
What you are seeing right now is the secure (container wise setup - before mapped volumes) solution for being able to use both file/path "standards" within the same container. This was done so that users keeping their dynamic zones in /etc (/etc/named or /etc/bind) could still have bind/named update them, even though /etc is not meant for dynamically service generated data.
After some time, I went back to the more popular and from what I can tell more widely used path/directory "standard" and unfortunately the /etc specific config/modifier stayed behind.
Either way, I would like to clean this up, so it probably makes sense.
One solution is to leave the chmod and make it 0640
The other is to remove it and rely on the "default" (which I think is 0644)
Thoughts?
Leaving it as default (which I guess is rw-r—r—) seems ok, but another option, if we want to remove other read access would be something like:
chmod -R o-rx /etc/bind
Which just affects the ‘o’ bits. Removing the ‘x’ seems like a good idea in case there are nested directories, it has no effect if ‘x’ wasn’t set to start with. I don’t think you can do this type of chmod using octal, it needs to be symbolic.
On 30 Apr 2020, at 19:00, Ventz Petkov [email protected] wrote:
@sgjohnston Thanks.
To your queston:
chmod -R 750 /etc/bind Why is that even needed?
Here is the background on this:
All of this started due to Bind ("named" service) having two main competing "standards" for where the "correct place to put things" is -- according to the official ISC2 released documentation. The problem is that some Linux distros implemented one and others implemented the other, while others implemented a hybrid in order to follow their own file/dir structure methodologies for configs vs "run-time" data vs "where service created things" live.
Looking at the main and still widely used systems - Debian vs Ubuntu vs RHEL vs CentOS vs AWS Linux vs OpenBSD vs Alpine have 3 different directory/permissions implementations between them, and 2 of those cannot co-exist on the same setup. To give you the complete list, in one they were in /etc/named, in another /etc/bind, in other they were in /var/named/cache or /var/cache/bind or /var/bind. I created this in 2014, on the first "non-alpha" Docker version and published it to Github in 2016 - at the time Alpine was not default for Docker containers, but the minimalism/size/security was attractive, and why I chose to go with Alpine.
I started following the more popular path/directory "standard" (Dynamic/bind-created live in /var/cache/bind) originally since it most widely adopted, and from what I can tell the semi-officially recognized one for everyone outside of RHEL/CentOS. Eventually someone brought up that the other competing "standard" should be supported for the users who want to use the file structure they are familiar with coming to Docker.
What you are seeing right now is the secure (container wise setup - before mapped volumes) solution for being able to use both file/path "standards" within the same container. This was done so that users keeping their dynamic zones in /etc (/etc/named or /etc/bind) could still have bind/named update them, even though /etc is not meant for dynamically service generated data.
After some time, I went back to the more popular and from what I can tell more widely used path/directory "standard" and unfortunately the /etc specific config/modifier stayed behind.
Either way, I would like to clean this up, so it probably makes sense.
One solution is to leave the chmod and make it 0640 The other is to remove it and rely on the "default" (which I think is 0644)
Thoughts?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.
@sgjohnston Ok, can you check commit: ~ca2aed6f0e306c1b51f0185d55d5518cadfbcf24~ Update: removed this commit in favor of: 8bdf77b
@ventz, unfortunately, that isn’t working - just running the container without any volumes attached files, because named can’t search the /etc/bind directory. What has happened is that
chmod -R 640 /etc/bind
has removed the execute permission from /etc/bind (the directory itself), which means that the daemon can no longer iterate through the files in the directory (I assume it does this); but anyway, it fails to start because of this. This is why I suggested using chmod -R o-rx, because that removes the execute permission for other users only, and doesn’t affect user and group.
On 1 May 2020, at 07:53, Ventz Petkov [email protected] wrote:
@sgjohnston https://github.com/sgjohnston Ok, can you check commit: ca2aed6 https://github.com/ventz/docker-bind/commit/ca2aed6f0e306c1b51f0185d55d5518cadfbcf24 — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ventz/docker-bind/issues/29#issuecomment-622274295, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA554GOMC3LUQO534ZYBAC3RPJWVBANCNFSM4JOWJTNQ.
@sgjohnston One more try (commit: ~be5f801~ try: 8bdf77b)
I want to keep the additive chmod (vs just subtracting for the group) because I suspect that at some point someone will add some files, volume map them, and the container won't start due to permission. Once the permission is set (truly one time - or if it was set correctly to begin with), this is not a problem.
@ventz, still not working I’m afraid :-) The problem is /etc/bind/default-zones is losing its ‘x’ permission, so named can’t read it. The same is also true for the other directory, /etc/named/example-configs, but that isn’t referenced from anywhere so doesn’t actually cause a problem.
On 1 May 2020, at 11:31, Ventz Petkov [email protected] wrote:
@sgjohnston https://github.com/sgjohnston One more try (commit: be5f801 https://github.com/ventz/docker-bind/commit/be5f801a080ebb32706ea37418339da0ce16acb1)
I want to keep the additive chmod (vs just subtracting for the group) because I suspect that at some point someone will add some files, volume map them, and the container won't start due to permission. Once the permission is set (truly one time - or if it was set correctly to begin with), this is not a problem.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ventz/docker-bind/issues/29#issuecomment-622335070, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA554GMWOEUF6MH2GJNIUKTRPKQHTANCNFSM4JOWJTNQ.
@sgjohnston Guess subtractive chmod it is :)
I need to get back to a computer - making these changes from a phone, so not able to test.
@sgjohnston I think this should work:
chmod -R 770 /etc/bind /var/cache/bind /var/run/named
find /etc/bind -type f -exec chmod 640 -- {} +
Yes, that works!
On 1 May 2020, at 12:03, Ventz Petkov [email protected] wrote:
@sgjohnston https://github.com/sgjohnston I think this should work:
chmod -R 770 /etc/bind /var/cache/bind /var/run/named find /etc/bind -type f -exec chmod 640 -- {} + — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ventz/docker-bind/issues/29#issuecomment-622345651, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA554GPK2VUR436TEFOTGCDRPKUADANCNFSM4JOWJTNQ.
Hi @ventz,
I’m sorry, I just realised that there’s still another permissions issue with docker-bind: /var/cache/bind should get the same treatment as /etc/bind, as there are also regular files in that directory which are getting execute permission added. So instead of:
find /etc/bind -type f -exec chmod 640 -- {} +
the following would resolve it:
find /etc/bind /var/cache/bind -type f -exec chmod 640 -- {} +
On 1 May 2020, at 12:09, Ventz Petkov [email protected] wrote:
Great - thanks for checking (and thank you for being patient with this!)
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ventz/docker-bind/issues/29#issuecomment-622347144, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA554GIGR3ZXJQQDQEKNVYTRPKUXBANCNFSM4JOWJTNQ.
Looks good!
On 12 May 2020, at 07:05, Ventz Petkov [email protected] wrote:
@sgjohnston https://github.com/sgjohnston All set d8691b7 https://github.com/ventz/docker-bind/commit/d8691b70766b635becab4494b7d581704c923914 — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ventz/docker-bind/issues/29#issuecomment-627129732, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA554GPHT7V2XEENZYX2MJ3RRDRJ5ANCNFSM4JOWJTNQ.