# Issues with permissions on Bind 9 log files



## DWAM (Sep 23, 2021)

Hi !

Very new to this FreeBSD universe. Installed my very first FreeBSD VM server yesterday even though I have been using pfSense and FreeNAS variants for over 10 years. Trying to find a reliable solution to switch from CentOS & Ubuntu servers for basic but important applications. I started my experiments with Bind 9. So far, so good except one thing : after a reboot, Bind won't start due to wrong permissions on logs (at least that's what I assume based on the syslog report).

Here's the logs reporting the issue

```
Sep 23 16:57:12 bsd01 named[798]: command channel listening on 127.0.0.1#953
Sep 23 16:57:12 bsd01 named[798]: isc_file_isplainfile '/var/log/named/default' failed: permission denied
Sep 23 16:57:12 bsd01 named[798]: configuring logging: permission denied
Sep 23 16:57:12 bsd01 named[798]: loading configuration: permission denied
Sep 23 16:57:12 bsd01 named[798]: exiting (due to fatal error)
Sep 23 16:57:12 bsd01 root[802]: /etc/rc: WARNING: failed to start named
```
Surprisingly if I start manually (via command or webmin), it starts and logs just fine...

I tried several ownerships (bind:bind, root:wheel, root:bind, etc...) and permissions on the directory and the logs files but still not OK and I'm not familiar with this wheel group or unix stuff.

Any clue on this logging permission error? Here's my current setup for /var/log/named/






While we're talking about ownership and permissions, I'm also wondering if my /usr/local/etc/namedb/ content is ok. I don't get it why the master folder is different and I had to change perms on my keys (it works as is but I'm not sure I chose the best solution)




Any help appreciated on this. Trial and error has limitations and Google couldn't find relevant info on this issue.

Thanks in advance. I can't wait to know more about FreeBSD !

Guillaume

PS : I forgot ! FreeBSD 13 - Bind 9.16.20


----------



## DWAM (Sep 25, 2021)

Finally found a working solution, not sure it is the correct one, but it works

I gave ownership to bind:wheel on /var/log/named/ folder with mode 0760... Quite weird but that's the only combination I tried which produced no error during the startup process after a reboot and had Bind to start correctly.

BTW after searching and reading so many pages on Bind and FreeBSD I'm quite sure I'm not doing it as it should and I'm very confused about the chroot setup (which I'm not using)... It's quite hard to figure out which information is valid between conflicting information between FreeBSD versions over time and handbook saying a different thing than the manual or posts on this forum...


----------



## Tieks (Sep 25, 2021)

DWAM said:


> I gave ownership to bind:wheel on /var/log/named/ folder with mode 0760


Folders (directory entries) always need to have their exec bit set, else you cannot access them. Could have been the problem indeed. If group members need to access that directory too, you need 0770.


----------



## SirDice (Sep 27, 2021)

The `bind` user needs write access to the log directory, so setting ownership to `bind:bind` and permissions to 750 should be fine.


----------



## ShelLuser (Sep 27, 2021)

Tieks said:


> Folders (directory entries) always need to have their exec bit set, else you cannot access them.


Not entirely true, you cannot check their contents but you can still access files in there, provided that you know the exact filename of course.


----------



## Tieks (Sep 27, 2021)

ShelLuser said:


> you cannot check their contents but you can still access files in there, provided that you know the exact filename


Used to Linux? It depends on the shell. Using csh, both `ls -la dirname` and `cat dirname/filename` give 'Permission denied' when that dir has no exec bits set. But I did notice in the past that Bash showed the somewhat weird behaviour that you describe. Don't know if it is still the case with current bash versions.


----------



## ShelLuser (Sep 29, 2021)

Tieks said:


> Used to Linux? It depends on the shell.


Errr, no, on both accounts. Permissions _hardly_ depend on the shell, that's silly, those are enforced by the kernel. If anything this behavior depends on the used file system, nothing more and nothing less.

For example: ZFS is known to behave slightly different than UFS in this regard, but even so, my above comment is fully to the point. I'd advice you to check out chmod(1) again.


----------



## Tieks (Sep 30, 2021)

ShelLuser said:


> my above comment is fully to the point.


Now that's fantastic! Are you always that moody?


----------



## ShelLuser (Oct 2, 2021)

Tieks said:


> Now that's fantastic! Are you always that moody?


Do you always try to make things personal whenever you don't like a comment? Assumption on my end, but still...

No, I'm not moody, _far_ from it actually. I can't help get the impression that you think I was attacking you or something? I wasn't. I merely corrected you because you shared incorrect info and that can have a negative effect for random readers.

If stuff like that gets you rallied up then maybe tech fora aren't your thing because that's how things usually work around here. This isn't about you or me, it's about random readers who may get the wrong ideas. When I see something wrong I try to correct it, just as I expect others to correct me whenever I'm wrong (which has also happened in the past).

Still, as mentioned: if you can only dish out and not take it... then maybe tech isn't the place for you.


On a more personal note: _intent_ and _perception_. Just because you perceive things to be "insulting" (?) doesn't automagically make that true ya know. If we go down that slope I might as well get offended over being called a Linux user despite not having used that mess (= my personal opinion) for well over 10 years. I never had the idea you were trying to offend me... I also fail to understand why you would think otherwise.

Within tech fora you can sometimes get called out for being wrong. It happens, it happens to most of us. That's the whole nature of why tech as a whole works in the first place.

Alas, I digress and get offtopic here.

</vent>


----------

