I encountered resolv.conf being created with 0600 permission upon reboot.
This prevents various non-root services (e.g. postfix) from resolving network names.
Steps to Reproduce:
1. set a value for "dns_servers_eth0" (or your interface) in /etc/conf.d/net
2. restart interface: /etc/init.d/net.eth0 restart
/etc/resolv.conf has permissions 0600, owned by root:root
/etc/resolv.conf should have 0644 permission
You should include the output of `ls -l /sbin/resolvconf; qfile -v /sbin/resolvconf`, if any. It an implementation of resolvconf is not found, the mode of /etc/resolv.conf is set to 644 after opening and writing. Otherwise, the file will be opened and modified by /sbin/resolvconf.
The net-dns/openresolv implementation explicitly sets the file mode creation mask to 022 before opening the file so, in theory, it should never be responsible for such an outcome.
there is no /sbin/resolvconf present on that system (output of `ls -l /sbin/resolvconf; qfile -v /sbin/resolvconf` empty) and net-dns/openresolv is not installed.
I'm not sure if anything else modified the file but since
# head -n1 /etc/resolv.conf
# Generated by netifrc for interface eth0
I suppose only netifrc is involved in my case.
If I could provide any more info, please let me know.
(In reply to Daniel Hiepler from comment #2)
> there is no /sbin/resolvconf present on that system (output of `ls -l
> /sbin/resolvconf; qfile -v /sbin/resolvconf` empty) and net-dns/openresolv
> is not installed.
In that case, chmod will always be invoked in an attempt to set the mode to 644. See line #58 of /lib/netifrc/net/system.sh. Further, in the case that the file didn't exist, it should be created with a mode of 644 anyway, because no steps are taken to restrict the umask.
For resolv.conf to be otherwise affected would normally entail the use of a DHCP client, such as udhcpc, dhclient or dhcpcd, be it at the behest of a netifrc helper script or otherwise. Note that, if you start a netfirc-managed interface that doesn't have an explicit config_* directive, it will attempt to start a dhcp client. So, the contents of your /etc/conf.d/net file and the output of `rc-status -a` might be interesting.
There is an explicit config_ setting:
# cat /etc/conf.d/net
config_eth0="192.168.0.1 netmask 255.255.255.0 brd 192.168.0.255"
routes_eth0="default via 192.168.0.254"
# rc-status -a
killprocs [ stopped ]
savecache [ stopped ]
mount-ro [ stopped ]
hwclock [ started ]
modules [ started ]
fsck [ started ]
root [ started ]
mtab [ started ]
swap [ started ]
localmount [ started ]
loopback [ started ]
procfs [ started ]
hostname [ started ]
termencoding [ started ]
keymaps [ started ]
sysctl [ started ]
bootmisc [ started ]
systemd-tmpfiles-setup [ started ]
save-termencoding [ started ]
binfmt [ started ]
save-keymaps [ started ]
seedrng [ started ]
devfs [ started ]
kmod-static-nodes [ started ]
sysfs [ started ]
udev [ started ]
dmesg [ started ]
cgroups [ started ]
systemd-tmpfiles-setup-dev [ started ]
udev-trigger [ started ]
local [ started ]
iptables [ started ]
fancontrol [ started ]
syslog-ng [ started ]
net.eth0 [ started ]
cronie [ started ]
mdadm [ started ]
netmount [ started ]
postfix [ started ]
smartd [ started ]
sshd [ started ]
local [ started ]
Dynamic Runlevel: hotplugged
Dynamic Runlevel: needed/wanted
munin-node [ started ]
Dynamic Runlevel: manual
ntp-client [ started ]
This is certainly a straightforward configuration. I can discern no apparent means by which netifrc might be responsible for the file mode being incorrect. Nevertheless, you could arrange for the "net.lo" script to be traced. Here is one strategy for doing so.
Firstly, insert the following lines into the /etc/init.d/net.lo script, beginning from line #2. Line #1 must remain intact as it is the "shebang" and needs to be parsed by the kernel.
echo "$(date -Is) $0: $*" >&2
echo "umask = $(umask)" >&2
Next, issue chmod 644 /etc/resolv.conf so that the file mode starts off as being correct. Finally, perform whichever steps are necessary for the /etc/resolv.conf file to end up with the incorrect mode. According to your initial report, restarting the interface is sufficient for that to occur. A log file will be created beneath /var/tmp, which you may attach to this report.
Note that the given definition of PS4 will vastly increase the utility of the log file but will have no effect unless /bin/sh is a symlink to bash. So, please ensure that is the case beforehand.
Incidentally, please also check that resolv.conf has not inadvertently been set to be immutable. The lsattr utility may be used to show the file's attributes.
I tried multiple times but couldn't reproduce the bug anymore. (I suppose re-emerging some package fixed the issue)
Marking this as resolved/invalid. When it happens again, I'll investigate further.
Thank you for your help.