> > On 27 November 1995 Adrian Phillips wrote: > > >>>>> "Philip" == Philip Tuckey <[EMAIL PROTECTED]> writes: > > > > Philip> However even using sudo was too much effort for me, so I > > Philip> did the following: > > > > Why ? Instead of sudo, you could try using super which I've just > > Well, with sudo I had to type in my password. I want an fvwm button I can > just click on, which didn't seem consistent with typing in my > password. Entirely possible I missed something of course. > > Will have a look at super, thanks for the suggestion. > > > Thats what sudo and super are for. > > With regard to pppd, is there any reason why the original debian package > cannot configure things so that users can execute pppd directly, presumably > with the protection of them having to be put into a special privileged > group, as is done for the devices? It seems more (and unnecessarily) > complicated for me to have to read the doc etc for sudo or super in order > to give users access, rather than just adding them to a special group. > > Regards > Philip >
I struggled with this problem as well. The trouble at the root of the problem (as you know) is that you want to store the password pppd will need to log into the remote system on your disk, but you don't want anyone to see it, right? So you put the login scripts into /etc/ppp and say chmod go-rwx /etc/ppp only to find that now when you start up pppd you get the error saying that it can't open the script file. "Ha-ha" you say, "I'll fix that!" and you say chown root /sbin/pppd chmod u+s /sbin/pppd and run it only to find that you get the same error. The trouble is that the authors of pppd thought it best to make the pppd program not be a security risk, so if you look in the source you'll see that when pppd runs the connect script, it forks, changing the effective uid to the real uid and execing the program. Thus if you're 'joe' and run pppd (pppd having the setuid bit set and owned by root) it runs with the effective uid of root and the real uid of joe. Of course then the script can't look at anything in /etc/ppp, which is where your scripts are. I solved this by modifying the code to keep both uid's to what the effective uid is. Then it works like a charm. Be warned, of course, that this is a potential security hole. (How likely it is that it can be compromised is open to debate). If I remember correctly, command line parameters to pppd override the 'options' file, so someone could just put an 'xterm' in for the connect script or a little program of their own to get root access to the machine. Personally, I think the need to be able to start pppd without being root is clear, and the need to be able to store passwords on disk is also clear, as is the need to keep them out of regular user's hands. Maybe someday this will be addressed. -- ============================================================================== = Jens B. Jorgensen | Blah. Blah blah blah, blah blah. = Citadel Investment Group, Inc. | Blah blah blah blah, blah blah. = [EMAIL PROTECTED] | = [EMAIL PROTECTED] | ==============================================================================
