Domain creating with incorrect permissions

[btaylor]

Greetings,

I am having an issue with a new install of DirectAdmin. When I create a new domain the .db file is created in /var/named with the wrong permissions (root.root instead of root.named). This causes the site to not route correctly. Anyone have any ideas?

 

[Richard G]

Oops, never mind... I deleted my previous message.

/var/named/domain.db is root:root so that's normal.

So your problem must caused by something else. Did you give it time to sync with global nameservers?

 

[btaylor]

Hmm, I guess you are right as I checked some other servers we host that are nameservers. I guess the problem is then that DNS will not route unless the file is owned by root.named but should work owned by root.root.

It also looks like if I try to restart named it gives an error unless /etc/named.conf is owned by root.named even though it is supposed to be root.root. I am beginning to think this may be an issue with named

 

[Richard G]

Question is what caused this named issue.

Did you check if the /var/named folder itself is root:named? Because that should be root:named and files in this folder are root:root. Maybe it's something with the rights?

drwxr-x---.  5 root named  24K Feb 10 00:10 named
-rw-r--r-- 1 root root 41K Feb 10 00:10 named.conf

Is the log not giving any hints about the problem?
Maybe you could extend your log capabilities in /etc/named.conf with something like this?

logging {
    channel default_log {
file "/var/log/named/default.log" versions 5 size 15M;
severity info;
print-category yes;
print-severity yes;
print-time yes;
    };
    channel security_log {
file "/var/log/named/security.log" versions 5 size 15M;
severity info;
print-category yes;
print-severity yes;
print-time yes;

For othes who are reading this, don't use it like this, it's missing tags and just placed here as an example.

 

[btaylor]

Thanks for the reply. We found that this was an issue with Directadmin not knowing how to properly handle named. In /etc/init.d/named named gets started with the `-u named` parameter. This forces named to run as the "named" user in the "named" group and is the correct way of doing things, because if someone remotely exploits the named service they won't automatically have a root shell but instead an unprivileged account with limited access.
So this was a problem with both permissions and ownership of the .db files. In order to work as root.root they needed to be created with 644 permissions but were being created with 640 permissions. To resolve we found the umask set in /etc/sysconfig/init for daemons was 027. DirectAdmin wasn't handling permissions on the named files, so this was resulting in root.root with 640 permissions. We changed the umask over to 022 and DirectAdmin now creates the files as 644.

This actually appears to be a bug that is happening on all or new DirectAdmin servers where the client hosts DNS on the server.

 

[Richard G]

Thank you for the explanation of what was happening.

is actually appears to be a bug that is happening on all or new DirectAdmin servers where the client hosts DNS on the server.

No that's not quite true. Because we've setup a new DA server in januari and I just had a look at /etc/sysconfig/init but there is no umask setting present. In my case it's a Centos 6.x 64-bit system.
So could te bug be limited to a certain Linux distro or version?