Month: July 2006

Recently I was asked to look into a problem involving BIND. DNS was not able to start via webmin, nor via /etc/rc.d/init, but named could could be manually started as root. While that works in the short run, that doesn’t solve the problem of the system surviving a reboot cleanly.

The only error named was reporting was:
Starting named: Error in named configuration: none:0: open: /etc/named.conf: permission denied

Obviously, this looks like a permission problem.

Normally, the trick, to solving it involves running named as root and looking at the error messages.
# named -g -u named

Problem is, as root, that worked. Not what I expected.

However, I found the problem and have a fix.

Bind used to run with the setuid bit, making it privileged, however in these security concious days, named now sheds its permissions. Even better, it is locked into a limited portion of the directory via chroot. That should be a big clue.

In FC4 and FC5, you’ll noted that /etc/named.conf is actually a symbolic link. It points into /var/named/chroot, where the process is jailed. In that directory you’ll find an a named, etc, and var directory. The etc directory mimcs all the needed files from /etc. The named directory has all the zone files. And the var directory has the pid and log files.

If named can’t run due to a permission problem, one should be looking under /var/named/chroot — which is how the process will see the world, not from /, like you do.

In my case, someone had run named as root, and that was enough to create a slave file in /var/named/chroot/var/named/slaves with an owner and group of root. Because the named process when running normally did not have permissions to replace this file with an update, named failed with a permission problem. I removed the file and was instantly able to start named from webmin as normal.

So there’s the trick. Look around in /var/named/chroot/var, /var/named/chroot/etc, and /var/named/chroot/named (and their subdirectories) and make sure all the things are readable to the named user, and the stuff that’s writable has the right owner, group, and permissions.

REMEMBER: when a config file says /etc or /var, it’s from the perspective of the chroot’d process — therefore you need to look where the process has been jailed to in the filesystem, and not what the path name looks like.

I still use FC4 quite a bit, but was surprised that sudo appears to be broken. It doesn’t work.

Even after adding user entries to /etc/sudoers, sudo will authenticate, showing the password, but won’t execute the command. For instance, sudo bash drops me back at the unprivileged shell.

The “problem” is actually PAM. The Pluggable Authentication Module.

If you hop over to the /etc/pam.d directory, you’ll discover that you need a sudo file. If one does not exist, then PAM will use other; and doing a cat on that file shows the default policy is to deny.

The quick solution is to simply something that works, such as the sshd file:
# cp sshd sudo

Or, at a minimum for Fedora Core 4, you can use this content:


/etc/pam.d$ cat sudo
#%PAM-1.0
auth required pam_stack.so service=system-auth
account required pam_stack.so service=system-auth
password required pam_stack.so service=system-auth
session required pam_limits.so


Note, though that for Fedora Core 5, things change a little:

#%PAM-1.0
auth include system-auth
account include system-auth
password include system-auth
session required pam_limits.so


Make sure you set the perissions and ownerships correctly:

# chown root sudo
# chgrp root sudo
# chmod 644 sudo
$ ls -l sudo
-rw-r--r-- 1 root root 203 Jul 5 2006 sudo


Please note that there is a yum distribution. You can add sudo to your system with:
# yum install sudo

Watch for warning messages. /etc/pam.d/sudo might need to be replaced with /etc/pam.d/sudo.newrpm, and /etc/sudoers might need to be replaced with /etc/sudoers.newrpm. This is simply yum not wanting to step on any existing files. Yum is the preferred way of installing sudo with FC4 and FC5.