Updated 13 October 2006
(Transferred from the wiki by Peter)
This PET relies heavily on my system configuration notes (dated 2004) to explain how to configure KPPP in Fedora Core systems. I either lost my original PET text, or did it online and didn't save a copy, so here goes:
This PET documents how to get KPPP to properly startup for a non-root user. Upon starting the kppp program as user horus for the first time after installing Fedora Core 1, I noted that it asked for the root password. I'd seen this before, with Red Hat from about 6.2 to 9.0, and wanted to do something about it. (I knew it was possible because Mandrake 9.2 works this way...)
Digging into this mystery, I discovered that Red Hat sets up kppp as a consolehelper app in PAM for security reasons. I am NOT an expert on PAM or on the finer aspects of Linux security yet. I do know that this method works.
Note: the KPPP Handbook is accessed by clicking on "Help" in the kppp dialog box. Read the section having to do with security and kppp very thoroughly. It isn't the whole picture, but it helps to understand how Red Hat et al at the Fedora Project have altered (read: messed up) kppp's default behavior.
Rather than bore you with all the changes I went through to get where I am now, with a working non-root kppp client, I'm just going to get on with the steps that really work.
Before we get into the steps, though, it is relevant to note that I had previously created a new group (kpppusers), added my kppp users to that group, and then created an /etc/kppp.allow file with kppp users listed in it. This is all covered adequately in the KPPP Handbook, so look at it for further details.
(Note: the easiest way I've found to create new groups is by using the 'Users and Groups' option under the 'System Settings' menu in KDE. You will, of course, need to be root or su'd to do this...)
On to the steps involved now...
- su to a root shell. (Open a terminal window, type in su, then give root's password when prompted...)
- delete the symlink to consolehelper by: rm /usr/bin/kppp
- alter permissions on /usr/sbin/kppp (the actual kppp binary) as follows: chmod u+s /usr/sbin/kppp (I think this actually sets kppp suid root)
- create a new symlink as follows: ln -s /usr/sbin/kppp /usr/bin/kppp
This allowed the kppp interface to come up without prompting for the root password, but now the error "can't create lock file on /dev/modem" occurs... could it be regular users do not have the required permissions to create the lock file?
- Add users to group lock (and to group kpppusers if not there already)
Note: for the next steps (which alter permissions for folders and files) I used and recommend using Midnight Commander if it is installed. Otherwise, you will need to clearly understand how to use the chmod command.
- Change ownerships/permissions on /var/lock to root root 0775
- Change ownerships/permissions on /var to root root 0775
- Check ownerships/permissions on /usr/sbin/kppp at root kpppusers 4775
- Change ownerships/permissions on /usr/sbin/pppd to root kpppusers 0755
- Change ownerships/permissions on /usr/sbin/pppdump to root kpppusers 0755
At this point, everything should work: on startup, kppp goes straight to the login/connect dialog box, and waits for you to press the connect button. When you do, voila, she works.
I've not used this setup in a while (ah - cable!), but I wonder...
- Do permissions on /usr/sbin/pppdump really need to be altered from their original defaults? Perhaps not?
- Is it possible to add group kpppusers to group lock instead of adding individual users to both groups? (I need to do more reading on groups, ownerships, and permissions anway.)
- Is this really sufficiently secure? Red Hat cited reasons of security for doing as they have - but is giving out the root password to every d@mned kppp user on your network really any better? I think not.
I'm sure there are other questions I can't answer yet about this setup, but this does work. As cable and DSL become more popular, this might not be as important in the more developed countries, but I'm sure this is still a burning question in areas where phone lines are still the only available infrastructure.