(*** This bug was imported into bugs.kde.org ***) Package: kppp Version: unknown (using KDE 2.2.0 ) Severity: normal Installed from: Mandrake Linux 8.1 (Cooker) Compiler: gcc version 2.96 20000731 (Mandrake Linux 8.1 2.96-0.60mdk) OS: Linux (i686) release 2.4.8-5mdk OS/Compiler notes: kppp changes the permissions on /etc/resolv.conf to -rw------- on any kind of disconnect which for a non root user is hopeless. This then seems to make talking over a dial up connection impossible. If the link timed out / dropped / disconnected the kppp dialog re-appears dialing will commence on pressing connect it will negotiate and the modem lights will appear. However it is a defunct connection since nothing appears to get in or out. If kppp is dismissed and re-started a dialog appears saying that /etc/resolve.conf does not exists. It does it just isn't accessible to a mere user. (Submitted via bugs.kde.org) (Called from KBugReport dialog)
This is a multi-part message in MIME format. ------=_NextPart_000_0019_01C13577.25F33240 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Each time when user is closing 'kppp' session the user rights for resolv.co= nf are changed so only root has the access to the file in consequence next = time when ppp starts it gives an error that resolv.conf is not there or not= available and name resolution is not working and priviledges changed by r= oot and again reverted at the end of ppp session. I have installed the Linux Mandrake version 8.1 beta 2. Thank you for your support Carlos ------=_NextPart_000_0019_01C13577.25F33240 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META http-equiv=3DContent-Type content=3D"text/html; charset=3Diso-8859-1"> <META content=3D"MSHTML 5.50.4522.1800" name=3DGENERATOR> <STYLE></STYLE> </HEAD> <BODY bgColor=3D#ffffff> <DIV><FONT face=3DArial>Each time when user is closing 'kppp' session the u= ser=20 rights for <U>resolv.conf</U> are changed so only root has the access to th= e=20 file in consequence next time when ppp starts it gives an error that resolv= .conf=20 is not there or not available and name resolution is not working=20 and priviledges changed by root and again reverted at the end of ppp= =20 session.</FONT></DIV> <DIV><FONT face=3DArial></FONT> </DIV> <DIV><FONT face=3DArial>I have installed the Linux Mandrake version 8.1 bet= a=20 2.</FONT></DIV> <DIV> </DIV> <DIV><FONT face=3DArial>Thank you for your support</FONT></DIV> <DIV><FONT face=3DArial></FONT> </DIV> <DIV><FONT face=3DArial>Carlos</FONT></DIV></BODY></HTML> ------=_NextPart_000_0019_01C13577.25F33240--
I have the same problem. CVS >= 20.12.2002, GENTOO cvs packages. The behaviour is as follows: - Before I start kppp, /etc/resolv.conf has 0644 perms, owner root, group root - After dialing and logging in, ls -l /etc/resolv.conf* looks like this: -rw-r--r-- 1 root users 224 Dec 24 15:35 /etc/resolv.conf -rw------- 1 root users 86 Dec 24 15:35 /etc/resolv.conf.old Note the backup (.old) perms, and note the group changes. After disconnection I have: (ls -l /etc/resolv.conf*) -rw------- 1 root users 86 Dec 24 15:35 /etc/resolv.conf Which results in kppp noticing a unaccessible /etc/resolv.conf on next start and no dns resolving for non-root users. I am surprised to see the original report being from 2001, so I hope someone is reading this. Let me know if you need further information.
> - After dialing and logging in, ls -l /etc/resolv.conf* looks like this: > -rw-r--r-- 1 root users 224 Dec 24 15:35 /etc/resolv.conf > -rw------- 1 root users 86 Dec 24 15:35 /etc/resolv.conf.old > > Note the backup (.old) perms, and note the group changes. Did you create the .old file ? > After disconnection I have: (ls -l /etc/resolv.conf*) > -rw------- 1 root users 86 Dec 24 15:35 /etc/resolv.conf The .old file disappeared without you deleting it ? The reason why I am asking: there is no code in kppp that creates backup files of resolv.conf. So if these happens I have to assume that a) your distribution contains either a modified version of kppp, or, b) there's some service or script (/etc/ppp/* ?) performing some action If either of this is true kppp is probably not at fault for the original file's permissions. I can't see any code that would creates this file and thus creates different permissions. > Which results in kppp noticing a unaccessible /etc/resolv.conf on next > start and no dns resolving for non-root users. They way kppp is installed by the original KDE package wouldn't make this a problem. What are the permissions of kppp ? Harri.
The following excerpt is part of a Gentoo Linux script # ip-up: add the server supplied DNS entries to # /etc/resolv.conf echo "/bin/cp -f /etc/resolv.conf /etc/resolv.conf.old" \ >>/etc/ppp/ip-up echo "/bin/cat /etc/ppp/resolv.conf >> /etc/resolv.conf" \ >>/etc/ppp/ip-up # ip-down: restore original /etc/resolv.conf echo "/bin/mv -f /etc/resolv.conf.old /etc/resolv.conf" \ >>/etc/ppp/ip-down I found at http://www.oclug.on.ca/archives/oclug/2002-August/022560.html. ip-up and up-down are run automatically by pppd. Depending on the umask value the cp and mv commands might screw up the permissions. A chmod 644 in there would help with your problem I think.
You are right. The problem was in ip-up/down. I am sorry for the false report. Thanks for your help.
Subject: Re: kppp changes permissions on /etc/resolv.conf In-Reply-To: <20030104100421.11591.qmail@ktown.kde.org> Message-ID: <Pine.LNX.4.10.10301041424240.23754-100000@lupinella.troll.no> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On 4 Jan 2003, Rolf Offermanns wrote: > You are right. The problem was in ip-up/down. > I am sorry for the false report. No problem. You couldn't know. Your information was very helpful to understand this problem and hopefully fix it for others. I've notified a Gentoo packager. > Thanks for your help. How did the scripts look like and what did you do exactly to fix the problem ? I'd like to update the kppp FAQ for other users. Thanks, Harri.