| Summary: | net-misc/netifrc: resolv.conf is created non world-readable | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Daniel Hiepler <d-too> |
| Component: | Current packages | Assignee: | netifrc Team <netifrc> |
| Status: | RESOLVED INVALID | ||
| Severity: | normal | CC: | gentoo, jstein, kfm |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Daniel Hiepler
2022-11-01 11:20:30 UTC
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 dns_domain_lo="local" dns_domain_eth0="example.com" config_eth0="192.168.0.1 netmask 255.255.255.0 brd 192.168.0.255" routes_eth0="default via 192.168.0.254" dns_servers_eth0="8.8.8.8 1.1.1.1" # rc-status -a Runlevel: shutdown killprocs [ stopped ] savecache [ stopped ] mount-ro [ stopped ] Runlevel: boot 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 ] Runlevel: sysinit devfs [ started ] kmod-static-nodes [ started ] sysfs [ started ] udev [ started ] dmesg [ started ] cgroups [ started ] systemd-tmpfiles-setup-dev [ started ] udev-trigger [ started ] Runlevel: nonetwork local [ started ] Runlevel: default 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. PS4='+$BASH_SOURCE:$LINENO: ' exec 2>>/var/tmp/net-runscript.log echo "$(date -Is) $0: $*" >&2 echo "umask = $(umask)" >&2 set -x 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. |