Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have a Debian 7 and a default installation of bind9, I manually changed permission of /etc/bind/named.conf to 000 and remove -u bind flag from /etc/default/bind9 just to see what happens.

As far as I know: when bind9 starts up as a run level 3 daemon, the init daemon invokes bind9 daemon script /etc/init.d/bind9 as root. The bind9 daemon script does not switch user, neither does bind9 program itself - because -u bind flag has already been removed.

But the problem is, bind9 fails to start and complains "permission denied" on /etc/bind/named.conf

If bind9 startup script was invoked by root, how can the permission problem occur?

To further clarify: there is no apparmor, selinux is disabled. The remainder of bind9 configuration is left at default.

share|improve this question
up vote 4 down vote accepted

Before named reads it's configuration file, it drops all but the necessary capabilities. The capability that allows root to bypass all file permission checks is CAP_FOWNER - see capabilities(7) if you're curious. If you check the bind source code, in bin/named/unix/os.c you'll find the functions linux_initialprivs() linux_minprivs() and others responsible for this behavior.

So, yes, your confusion is understandable. uid 0 will normally have CAP_FOWNER and thus a process operating as uid 0 would be able to operate unhindered by most file access and permission checks. In this case, bind irrevocably drops all privileges not expressly needed for operation. In my opinion, that's a very reasonable and prudent action for the daemon to do.

To avoid the problem, consider changing the permissions on that configuration file to simply 0400 which allows uid=0 to read the file without relying on CAP_FOWNER.

share|improve this answer

Of course it will fails since you disallowed read/write/execution permissions on /etc/bind/named.conf. Try using chmod ugo+r /etc/bind/named.conf && chown root /etc/bind/named.conf and try again.

Explaining why

Let's see how named reads the file.

sudo strace -f /usr/sbin/named -fg -d 10 2> named

This will show all the calls over files that named/bind does. Now processing:

grep conf named                                  
read(5, "#\n# OpenSSL example configuratio"..., 4096) = 4096
write(2, "08-Feb-2014 14:01:42.372 built w"..., 39108-Feb-2014 14:01:42.372 built with '--prefix=/usr' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--sysconfdir=/etc/bind' '--localstatedir=/var' '--enable-threads' '--enable-largefile' '--with-libtool' '--enable-shared' '--enable-static' '--with-openssl=/usr' '--with-gssapi=/usr' '--with-gnu-ld' '--with-geoip=/usr' '--enable-ipv6' 'CFLAGS=-fno-strict-aliasing -DDIG_SIGCHASE -O2'
[pid 25348] write(2, "08-Feb-2014 14:01:42.395 loading"..., 7508-Feb-2014 14:01:42.395 loading configuration from '/etc/bind/named.conf'
[pid 25348] open("/etc/bind/named.conf", O_RDONLY|O_LARGEFILE) = -1 EACCES (Permission denied)
[pid 25348] write(2, "08-Feb-2014 14:01:42.396 open: /"..., 7108-Feb-2014 14:01:42.396 open: /etc/bind/named.conf: permission denied
[pid 25348] write(2, "08-Feb-2014 14:01:42.399 load_co"..., 6308-Feb-2014 14:01:42.399 load_configuration: permission denied
[pid 25348] write(2, "08-Feb-2014 14:01:42.400 loading"..., 6608-Feb-2014 14:01:42.400 loading configuration: permission denied

Named tries to do a open call as readonly and fails with -1 EACCES since the file doesn't have read permissions. This is documented in the open() manual pages:


Search permission is denied on a component of the path prefix, or the file exists and the permissions specified by oflag are denied, or the file does not exist and write permission is denied for the parent directory of the file to be created, or O_TRUNC is specified and write permission is denied.

Summary: that apache or any other process works doesn't mean that bind/named will.

BTW, running bind as root is overkill and is not necessary.

share|improve this answer
I did chmod -R 000 /etc/apache2 and apache2 does not complain. – Howard Feb 8 '14 at 16:55
"Permission denied" never happens to root user when it attempts to read a file. Linux does not stop root from reading any file in file system no matter what permission the file has. Bind daemon or the daemon script probably switched user somehow, and that's what I would like to get answer of. – Howard Feb 8 '14 at 17:05
Sans extra security measures, root can read any file. – Ricky Beam Feb 8 '14 at 22:00
No it doesn't. BY DEFAULT, root can open any file. ---------- 1 root root 0 Feb 8 19:29 foo -> open("foo", O_RDONLY) = 3 – Ricky Beam Feb 9 '14 at 0:31
@Braiam, (i submitted an answer, but I thought I'd add this tidbit here) any process with the capabilities(7) CAP_FOWNER is able to bypass most all filesystem permission tests. The core piece of logic seems to be in the kernel in the function inode_owner_or_capable() in fs/inode.c of the kernel source. Normally, uid 0 processes have CAP_FOWNER, but bind9 specifically drops that privilege at startup before it reads the config file. – etherfish Feb 12 '14 at 19:43

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.