Red Hat Bugzilla – Bug 9482
/etc/resolv.conf created with readonly root permissions
Last modified: 2008-05-01 11:37:54 EDT
When rp3 is used with a dialup connection that specifies DNS servers, it
creates a new /etc/resolv.conf with those servers, but the permissions on
the file are 600, so DNS lookups by any other users fail.
Also, if there is already an /etc/resolv.conf before rp3 is used, shouldn't
it save the original file somewhere and then restore it once the connection
Restoring the previous contents of /etc/resolv.conf becomes very difficult if
you start mixing multiple PPP interfaces, so it's not something I expect rp3
will be able to do any time soon, if ever.
The resolv.conf is modified by the ifup-post script, which takes pains to
maintain the existing permissions on the file. If you use chmod to reset the
permissions to 0644, does it get changed back to mode 0600 when you bring up a
It seems to be ok on preserving permissions if /etc/resolv.conf exists
beforehand, but if the file doesn't exist before dialing, the new one it
creates gets 600 permissions.
What is your umask set to (i.e., what does running "umask" print) when you bring
up the interface? The permissions set on new files can never include those in
your umask, so if your umask is set to 077, then the file can't be created with
permissions greater than 0600.
"umask" for root (right before invoking rp3) is '022'.
Also I have confirmed that if rp3 is run when no /etc/resolv.conf
exists, the created file gets permissions 600. But if it previously
existed, the permissions are correctly preserved.
Ugh. As far as I can tell, rp3 and wvdial never directly modify this file, and
leave it to the initscripts package's scripts to do the work. Initscripts
doesn't modify the file permissions either way, so files that get created get
the default permissions, and permissions on pre-existing files remain unchanged.
I suspect that somewhere in the whole rp3->wvdial->ifup->ifup-post chain of
execution something is changing the default umask to 077. Putting a fix into
initscripts is probably the best way to work around the problem.
Fixed in initscripts-5.02-1.