Bug 20665 - named does not have permission to open named.run
Summary: named does not have permission to open named.run
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: bind   
(Show other bugs)
Version: 7.0
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Bernhard Rosenkraenzer
QA Contact: Dale Lovelace
Depends On:
TreeView+ depends on / blocked
Reported: 2000-11-10 23:53 UTC by Need Real Name
Modified: 2005-10-31 22:00 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2000-12-20 16:51:44 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Need Real Name 2000-11-10 23:53:20 UTC
When I sent named SIGUSR1 to turn on a debugging run, the following
appeared in the system log:

Nov 11 09:16:35 janus named[1729]: log_open_stream: open(named.run) failed:
Permission denied
Nov 11 09:16:35 janus named[1729]: log_open_stream: open(named.run) failed:
Permission denied

A name server dump, also, does not seem to produce an output file,
although no error is reported.

/var/tmp has permissions drwxrwxrwt
/var/run has permissions drwxr-xr-x (setting permissions to drwxrwxrwx had
no effect)

Comment 1 Need Real Name 2000-12-20 16:34:48 UTC
This error occurs in normal operation.

Dec 20 11:26:51 hostname named[2628]: couldn't create pid 
file '/var/run/named.pid'

Cause: default bind RPM install runs as user/group "named"; this user does not 
have write permissions for /var/run

Solution: move the bind PID file to a directory which is owned by the 
user "named".  From Bernhard's comments, this should apply to *all* files 
created by the Bind daemon which it may want to create or re-create after 
dropping root permissions.

I would increase the priority of this bug to "medium" but don't see how.

Comment 2 Daniel Senie 2000-12-20 16:51:42 UTC
This appears to be a dupe of a bug I submitted. Also, it covers ALL platforms, not just 7.0.

Is anyone from RedHat reading this stuff? Does anyone care that you released a supposed security fix that resulted in failure of people's name servers? 
Hello? Anyone home?

Comment 3 Bernhard Rosenkraenzer 2000-12-20 22:29:13 UTC
9.1.0-0.b1.3 fixes this problem by moving the files to /var/run/named - /var/run
isn't writable by non-root users (and running named as root isn't a good thing).

Comment 4 Daniel Senie 2000-12-20 22:43:34 UTC
It is possible to make the EXISTING version work in /var/run/named as well, indeed I recommended that approach in another bug report quite some time 
ago. It would be nice if RedHat released a fix based on the PRESENT version of bind, rather than jumping to bind-9, which is largely untested. This is 
eminently fixable as a BUG FIX, without adding new functionality. The real issue here is Redhat released a "security patch" which fixed a bug in the 
underlying BIND code, but at the same time also incorporated half-baked changes to make the daemon not run as root.

The fix for this bug is NOT to release something based on bind-9. If that's RedHat's answer, I think it'll be time to look for another Linux distribution, 
hopefully one which understands how to make security fixes without de-stabilizing systems.

Comment 5 Bernhard Rosenkraenzer 2000-12-20 23:01:06 UTC
Yes, it's possible to move the bind 8.x PID files to a different subdirectory
with a relatively simple patch.
Do you see a good reason why this would warrant an errata? The absence of the
PID files hasn't hurt the stability or performance of our DNS servers so far.

Comment 6 Bernhard Rosenkraenzer 2000-12-20 23:06:40 UTC
("Resolved RAWHIDE" usually means as much as "It's fixed in our current tree, so
it will be fixed in the next release. We don't consider this bug big enough to
release an errata package, unless you have good arguments for it, in which case
you should reopen the bug")

Comment 7 Daniel Senie 2000-12-20 23:11:41 UTC
This is actually an extremely serious problem. Read my other bug report on the issue. It's not just the PID file we're dealing with here. The PID file could 
be handled by posting a text-only errata explaining the work-around. However, since the update package changes to a new UID/GID, changes the 
/var/named directory ownership, BUT NOT the files within /var/named, every secondary name server out there will be broken. Bind creates more files than 
just the PID file, and copies of those other files can and will exist from before applying this errata patch you presently have out there.

Note You need to log in before you can comment on or make changes to this bug.