see also bug #26311 /etc/ppp/ip-up and ip-down (ppp-2.4.2_beta3-r1) change the permissions of /etc/resolv.conf: /bin/chmod 640 /etc/resolv.conf /bin/chown root:users /etc/resolv.conf I'm using rp-pppoe, which keeps resolv.conf in /etc/ppp/ and makes a symbolic link from /etc/resolv.conf -> /etc/ppp/resolv.conf (which is owned by root:root) So please change the command in ip-up to: /bin/chown --dereference root:users /etc/resolv.conf to take care of a possible symlink
*** Bug 37295 has been marked as a duplicate of this bug. ***
sounds good, fixed :D
Does not work for me yet. /etc/ppp/ip-up has the line /bin/chown --no-dereference root:users /etc/resolv.conf Shouln't it be "--dereference" instead of "--no-dereference"?
ok, i don't really understand why we need this at all, ip-up does the following: move /etc/resolv.conf to /etc/resolv.conf.old cat /etc/ppp/resolv.conf to /etc/resolv.conf and change ownership of /etc/resolv.conf to the user so /etc/resolv.conf is in no case a symlink and you should have the correct rights
I confirm what s.kapfinger@gmx.de has described: when using rp-pppoe, adsl-start keeps resolv.conf in /etc/ppp/ and makes a symbolic link from /etc/resolv.conf -> /etc/ppp/resolv.conf: # adsl-start # ls -l /etc/resolv.conf* /etc/ppp/resolv.conf -rw-r----- 1 root users 52 Jan 12 18:24 /etc/ppp/resolv.conf lrwxrwxrwx 1 root root 20 Jan 12 18:23 /etc/resolv.conf -> /etc/ppp/resolv.conf -rw------- 1 root root 52 Jan 12 18:24 /etc/resolv.conf.old What is happening is that ip-up is not really moving /etc/resolv.conf to /etc/resolv.conf.old, but making a copy (command used is "cp -f"). So after that, the file /etc/resolv.conf is still there. If it was a link, it still is a link. Then ip-up appends /etc/ppp/resolv.conf to /etc/resolv.conf using a "cat >>" command. Conclusion: a new /etc/resolv.conf is not created. A "rm /etc/resolv.conf" command after the "cp -f" and before the "cat" command solves the problem.
I have observed also that the service domainname (script /etc/init.d/domainname) creates a new /etc/resolv.conf, in order to put the domain in the first line, leaving it unreadable by normal users.
it should be readable since files are generated 0644 by default, hopefully finally fixed the resolv.conf issues in ppp
*** Bug 49697 has been marked as a duplicate of this bug. ***
Well ... I just upgraded from net-dialup/ppp-2.4.1-r14 to net-dialup/ppp-2.4.2-r2 and I now have a resolv.conf that can only be read by root. I am using "kppp" to dial out.
pppd passes USEPEERDNS=1 as environment variable to ip-up script also when gentoo's net.ppp0 specifies usepeerdns='no' (prolly when the ppp server passes dns servers back) the ip-up script sees the =1 and rewrites resolv.conf at umask = 0077, resulting in a resolv.conf with permissions 400 and total system name resolution breakage for anything sane enough to not run as root. Somebody please reopen this bug and fix this.. took ages to track this :(
reopening
Ok, I've looked into sources of ppp-2.4.2. Don't see any problem in there; the env variable USEPEERDNS is set only when "usepeerdns" is present in command line of pppd or in system options (/etc/ppp/options*). Are you sure you don't have this flag set?
You won't find it in the ppp sources, the flaw is the ip-up script (/usr/portage/net-dialup/ppp/files/2.4.2/ip-up) which will recreate with very strict umask the /etc/resolv.conf script, depending on how a user configs his ppp uplink. Don't think thats acceptable. No the bug is not obvious, cus its the umask the script is run as that causes the strict permission settings on /etc/resolv.conf
*** Bug 62864 has been marked as a duplicate of this bug. ***
*** Bug 26311 has been marked as a duplicate of this bug. ***
fixed, resolv.conf is now chmod 644 at the end of ip-up.
*** Bug 69694 has been marked as a duplicate of this bug. ***
Please reopen this bug (I am not allowed to do that) ppp 2.4.2-r7, which just got pushed out to stable gentoo users, contains "chmod 640 /etc/resolv.conf" in /etc/ppp/ip-up.d, which according to comment #17 should have been fixed already. This breaks name resolution for all non-root users not in group "users".
fixed again - thank you for your astute attention.
There seems to be something wrong in the bug fixing process. I just received ppp-2.4.2-r8 with a ChangeLog entry that this bug has been fixed in files/net.ppp0. That file indeed seems to put chmod 644 /etc/resolv.conf into the ip-up script. However, the new file /etc/ppp/ip-up I received *still* has the chmod 640 in it and does not look like it has been generated by files/net.ppp0 at all (Attachment to follow). So perhaps there is some confusion about how that config file is generated? Please reopen this bug (I am not allowed to). Portage 2.0.51-r3 (default-linux/x86/2004.3, gcc-3.3.4, glibc-2.3.4.20040808-r1, 2.6.8.1 i686) ================================================================= System uname: 2.6.8.1 i686 Intel(R) Pentium(R) 4 CPU 2.60GHz Gentoo Base System version 1.4.16 Autoconf: sys-devel/autoconf-2.59-r5 Automake: sys-devel/automake-1.8.5-r1 Binutils: sys-devel/binutils-2.14.90.0.8-r1 Headers: sys-kernel/linux26-headers-2.6.8.1-r1 Libtools: sys-devel/libtool-1.5.2-r5 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-march=pentium4 -O2 -pipe" CHOST="i686-pc-linux-gnu" COMPILER="" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.1/share/config /usr/kde/3.2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3/share/config /usr/lib/mozilla/defaults/pref /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=pentium4 -O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache distlocks fixpackages noauto notitles sandbox sfperms userpriv usersandbox" GENTOO_MIRRORS="http://linux.rz.ruhr-uni-bochum.de/download/gentoo-mirror/ http://ftp.uni-erlangen.de/pub/mirrors/gentoo http://gentoo.inode.at/ http://gentoo.mirror.sdv.fr http://www.ibiblio.org/pub/Linux/distributions/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.de.gentoo.org/gentoo-portage/" USE="X acpi alsa avi berkdb bitmap-fonts cdr crypt cups dvd emacs encode esd f77 fam flac foomaticdb fortran gdbm gif gnome gphoto2 gpm gstreamer gtk gtk2 guile imagemagick imlib jack java jpeg junit libg++ libwww mad mbox mikmod mmx mmx2 motif mozilla mpeg nas ncurses network nptl oggvorbis opengl pam pdflib perl png python qt quicktime readline rtc samba sdl slang speex spell sse sse2 ssl svga tcpd tetex theora tiff truetype usb x86 xml xml2 xmms xv xvid zlib"
Created attachment 43687 [details] /etc/ppp/ip-up as installed by ppp-2.4.2-r8 Note that this file still has the bad chmod 640 in it, and is different from what files/net.ppp0 would generate. Perhaps there are several places that might generate the ip-up file, and the one you fixed is *not* the one that actually does it. I suggest to reduce the ip-up generators/sources to one, so that there can be no confusion which generator/source actually needs to be fixed.
The ChangeLog is correct; it was a change in files/net.ppp0. However, this file is not used by 2.4.2 versions which instead use files from "files/2.4.2". In this version, /etc/ppp/ip-up isn't it generated by /etc/init.d/net.ppp0 and I strongly feel this is the correct behaviour. However, it is strange that ip-up script generate a root:users 0640 resolv.conf. Nameservers should not be classified information. Corrected in 2.4.2-r9
