-- BEGIN included message
- To: yellowdog-general@lists.yellowdoglinux.com
- Subject: Re: After installing YDL 1.2, problems with Xlib: connection to":0.0"refused by server
- From: pac1@tiac.net
- Date: Wed, 12 Apr 2000 22:06:55 -0400
- References: <Pine.LNX.4.10.10004120920020.19173-100000@vyger.penguinpowered.com>
Nathan Hjelm wrote: > you can set the suid bit on kppp to fix that problem, as for the other, > if you are using x as one user and trying to make a connection to that as > another user it will not work until you tell x to allow connections from > other users on the local machine by typing xhost +localhost > > > > >Sounds like you are trying to run kppp as someone other than the user > > >that started the X session. Try doing an xhost + in a shell logged in > > >as the user who started X before doing the kppp. Do a man xhost if you > > >want to be more restrictive with the access control. > > > > > >Jim > > This is indeed what is going on, and adding xhost + localhost is an apparent fix. Not so fast though, there's actually two puzzles in to solve here. The first is how to get kppp to connect to the x server without resorting to xhost. The second is to figure out why kppp insists on asking for the root password every time you try to start it as anyone but root. In YDL 1.2 apparently the default security features for X have been tightened up a bit. These changes may be in kde rpms or XFree86 rpms. or something else. I'm not sure which. Anyone know? There have been changes in YDL1.2 's X implementation. These may be in kde, Xfree86 or some other packages. The net result is that prefdm is no longer automatically started at boot. To get going in X, I logged in as root in the console and gave the command /etc/X11/prefdm& which got me the login screen I saw in YDL 1.1 and started prefdm manually. I'll step through the procedure and annotate the processes that get started at each step below. Keep in mind the following changes from YDL 1.1: 1. X is started with -auth. you don't get -auth by default in 1.1 2. Pam, userhelper and consolehelper are involved in the starting of kppp To get a grip on this, follow this account of starting up and getting kppp running. Boot into YDL. login:root You should see processes like these using ps -aux root 497 0.0 1.0 3492 1284 tty1 S 20:49 0:00 login -- root root 498 0.0 0.4 1192 516 tty2 S 20:49 0:00 /sbin/mingetty tty2 root 499 0.0 0.4 1192 516 tty3 S 20:49 0:00 /sbin/mingetty tty3 root 500 0.0 0.4 1192 516 tty4 S 20:49 0:00 /sbin/mingetty tty4 root 501 0.0 0.4 1192 516 tty5 S 20:49 0:00 /sbin/mingetty tty5 root 502 0.0 0.4 1192 516 tty6 S 20:49 0:00 /sbin/mingetty tty6 root 516 0.0 1.0 2568 1372 tty1 S 21:01 0:00 -bash Wait at least 60 seconds, so we don't lose track of what started when. Next start /etc/X11/prefdm& from the console. The login window shows up and the following processes are there. We can't see them just yet because we haven't logged in. So we'll wait another 60 seconds so we can tell them from processes started by logging in. root 548 0.0 2.6 7980 3416 ? S 21:03 0:00 /usr/bin/kdm root 550 1.3 4.3 9136 5512 ? R 21:03 0:08 /etc/X11/X -auth /usr/X11R6/lib/X11/xdm/authdir/A:0-cPrmKH root 554 0.0 4.2 9844 5364 ? S 21:03 0:00 -:0 see how X was started with -auth in process 550? After waiting one more minute, use the login screen and immediately start a terminal window and do ps -aux to see what's cooking. pac1 567 0.1 4.4 8416 5628 ? S 21:04 0:00 kwm pac1 595 0.0 3.9 8716 5044 ? S 21:04 0:00 kbgndwm pac1 622 0.1 5.1 11288 6492 ? S 21:04 0:00 kfm pac1 623 0.0 3.8 7852 4860 ? S 21:04 0:00 krootwm pac1 624 0.1 4.7 9172 6068 ? S 21:04 0:00 kpanel pac1 633 0.0 0.6 1880 824 ? S 21:05 0:00 /usr/bin/autorun --interval=1000 --cdplayer=/usr/bin/kscd pac1 634 0.0 4.3 8988 5464 ? S 21:05 0:00 konsole -icon konsole.xpm -miniicon konsole.xpmi -caption Konsole pac1 635 0.0 1.0 2556 1328 pts/0 S 21:05 0:00 /bin/bash I list the kppp & pppd directory entries to see what I've got. Note that niether kppp or pppd is suid! They do not need to be, and it makes no difference if they are. bash-2.03$ ls -lah /usr/sbin/*ppp* -rwxr-xr-x 1 root root 375k Feb 28 04:29 /usr/sbin/kppp -rwxr-xr-x 1 root root 167k Feb 27 22:34 /usr/sbin/pppd -rwxr-xr-x 1 root daemon 44k Feb 27 22:34 /usr/sbin/pppdump -rwxr-xr-x 1 root daemon 10k Feb 27 22:34 /usr/sbin/pppstats ls -lah /dev/modem crw------- 2 root root 5, 64 Apr 12 21:20 /dev/modem Note that nothing is set to suid at this point, root owns everything and the modem can only be read or written by root! The next thing to do is xhost +localhost enabling kppp to operate without the annoyning Xlib: connection to ":0.0" refused by server messages. I think this is an interim solution to the X connection problems for kppp. There's got to be a better or right way to do this without falling back to xhost. Does anyone know what it might be? Let's table that issue and move on and get connected to the internet so I can send this message out. You can successfully start kppp& at this point, but it requires the root password in a pop-up before presenting the usual connection window. before responding, do another ps -aux to see what got started. It shows: root 744 0.7 2.2 5312 2808 pts/0 S 21:25 0:00 kppp root 745 0.1 0.7 3000 972 pts/0 S 21:25 0:00 /usr/sbin/userhelper -w kppp Oooo what's that? userhelper? that's new! man userhelper indicates that this is a part of pam! Well I'll be sprayed! "This program provides a basic interface to change a user's password, gecos information, and shell. The main dif<AD> fernce between this program and its traditional equivilents is that prompts come out on standard out to make it easy for a GUI program to interface it as a child process. " "userhelper is normally called from consolehelper via a symlink." Ah Ha! ls -lah /usr/bin/kppp lrwxrwxrwx 1 root root 13 Apr 11 19:43 /usr/bin/kppp -> consolehelper so where's the symlink to userhelper? Anybody found this yet? I haven't. So that's what this new thing is. In 1.1, /usr/bin/kppp did not exist. since it's first in the path, it gets executed when you say kppp& not the same thing at all as 1.1 where /usr/sbin/kppp would just start executing and it had to be suid. We're almost there, most of the pieces of the puzzle are found, we just need to find a few more and put them together to understand what's going on. What's the right way to set things up? I'm still unsure. I've a feeling that most experienced users do not use kppp or even kde, so they don't run into this. In anycase, the community needs a bit more knowlege of X servers to move away from the xhost +localhost solution, and a bit of knowlege about pam and kppp's useage of pam. Whew. This was a long one. Congratulations if you've read all this to the end.
-- END included message