Re: User invocation of pppd (Re: diald & pppd trouble query)
>
> On 27 November 1995 Adrian Phillips wrote:
> > >>>>> "Philip" == Philip Tuckey <pat@rs3.univ-fcomte.fr> 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.
= jbj1@wfg.com |
= jbj1@uchicago.edu |
==============================================================================
Reply to: