Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

pppd permissions

717 views
Skip to first unread message

Rob Love

unread,
Aug 18, 2000, 3:00:00 AM8/18/00
to
Hello,
I would like to be able to run the pppd with the noauth option as a
non-root user. I have run "chmod 777 /usr/sbin/pppd", but it tells me that
the option noauth requires root privilidges. I am not sure what else to
do... Do I need to set up a group that can use the pppd and set it's
permissions to root? I'm not really sure how to go about that...

well, thanks
Rob Love

Bill Unruh

unread,
Aug 19, 2000, 11:03:06 PM8/19/00
to
In <8nkgtt$n...@news.or.intel.com> "Rob Love" <robert...@intel.com> writes:

>Hello,
> I would like to be able to run the pppd with the noauth option as a
>non-root user. I have run "chmod 777 /usr/sbin/pppd", but it tells me that

It needs to be
chmod go-w /usr/sbin/pppd
chmod u+s /usr/sbin/pppd
AND the noauth option needs to be put intw /etc/ppp/options.

(if you leave pppd writable and suid root, it becomes trivial for anyone
to break into your system as root).

Bill Unruh

unread,
Aug 19, 2000, 11:04:11 PM8/19/00
to
In <399f...@news.acadiacom.net> nos...@fastband.com (Dave) writes:

]Depends upon the version. With some versions you can do "chmod 4711 ..." to
]get it to run with root priveleges (assuming that the owner is root), but
]other versions make a system call to see who started the process, and if it
]wasn't root, refuse to allow the noauth option.

]I was forced to hack the source code in that case to bypass the check.

Just put noauth into /etc/ppp/options ( making sure it is not user
writable).

Rob Love

unread,
Aug 20, 2000, 3:00:00 AM8/20/00
to
I have written a full communications program in C++ and I call the pppd
from the C++ code. I am really trying to avoid having to modify any other
scripts or option files. The C++ code just makes a system call to the pppd
and passes it the parameters that I want. The only one that I can't get to
work from the command line is the "noauth". Well I can do it as root, but
not as a non-root user the noauth option has to be in the options file.
Permissions in general aren't the problem really, it's just this one
particular argument. I am not sure if I can get around putting it in the
options file though. It seems that it is a security issue that I'm not gonna
get around and maby that's good. I just wanted to throw it to you guys and
see what I got back...

Thanks,
Rob Love

Bill Unruh <un...@physics.ubc.ca> wrote in message
news:8nnhpa$m78$1...@nntp.itservices.ubc.ca...

James Carlson

unread,
Aug 20, 2000, 3:00:00 AM8/20/00
to
nos...@fastband.com (Dave) writes:
> On 20 Aug 2000 03:04:11 GMT, Bill Unruh <un...@physics.ubc.ca> wrote:
> : Just put noauth into /etc/ppp/options ( making sure it is not user
> : writable).
>
> As I said, depends upon the version.

You did say that, but it's still not true. All options read from
/etc/ppp/options, /etc/ppp/options.ttyname, and /etc/ppp/peers/name
are always privileged. Options placed on the command line or in
~/.ppprc have the invoker's privilege. (Option files read by the
"file" option have the same privilege level as the place where the
option itself occurs.)

--
James Carlson <car...@workingcode.com>
"PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp

James Carlson

unread,
Aug 20, 2000, 3:00:00 AM8/20/00
to
"Rob Love" <robert...@intel.com> writes:
> I have written a full communications program in C++ and I call the pppd
> from the C++ code. I am really trying to avoid having to modify any other
> scripts or option files. The C++ code just makes a system call to the pppd
> and passes it the parameters that I want. The only one that I can't get to
> work from the command line is the "noauth".

Right. That's by design. You can nuke the code in pppd/auth.c that
checks the privilege level (just change OPT_PRIV to 0), but you'll be
opening a security hole on some systems.

By default, pppd insists on authenticating the peer if the local
system has a default route. The assumption is that if you have a
default route (and your system isn't just misconfigured), then that
points to an important network (or the Internet itself), and allowing
unauthenticated users to have access to that is a bad idea.
Otherwise, if there's no default route, then pppd doesn't bother
authenticating the peer unless requested with the "auth" option.

There are several ways you can "get around" this feature. One is to
use the pppd "call" option and put "noauth" in the corresponding
/etc/ppp/peers/ file. (Assuming your communications package has some
sort of installation procedure, you could have this special file
automatically added to the user's configuration.)

Bill Unruh

unread,
Aug 20, 2000, 3:00:00 AM8/20/00
to
In <8np23d$4...@news.or.intel.com> "Rob Love" <robert...@intel.com> writes:

] I have written a full communications program in C++ and I call the pppd
]from the C++ code. I am really trying to avoid having to modify any other
]scripts or option files. The C++ code just makes a system call to the pppd
]and passes it the parameters that I want. The only one that I can't get to

]work from the command line is the "noauth". Well I can do it as root, but


]not as a non-root user the noauth option has to be in the options file.
]Permissions in general aren't the problem really, it's just this one
]particular argument. I am not sure if I can get around putting it in the
]options file though. It seems that it is a security issue that I'm not gonna
]get around and maby that's good. I just wanted to throw it to you guys and
]see what I got back...

It is a security issue. If a user were able to start up pppd with root
priviledges on your system with the noauth option, it would leave your
system completely open to anyone getting onto your system, even as root,
without you requiring anything from him. A very very very bad idea.

Why are you adverse to putting noauth into the options file if that is
what you want? Besides, for call outs noauth is the default, unless you
also have an ethernet connection with a default route on that ehternet.
Are you sure you want that?

You can also put it into other priviledged files
(/etc/ppp/peers/options) and use the call option for pppd to read it
from those if you so desire. (Make sure that those files are writable
only by root).

]Thanks,
] Rob Love

]Bill Unruh <un...@physics.ubc.ca> wrote in message
]news:8nnhpa$m78$1...@nntp.itservices.ubc.ca...

]> In <8nkgtt$n...@news.or.intel.com> "Rob Love" <robert...@intel.com>

]>
]>

James Carlson

unread,
Aug 21, 2000, 3:00:00 AM8/21/00
to
nos...@fastband.com (Dave) writes:
> From main.c:
>
> int privileged; /* we're running as real uid root */
> ...
> if (!options_from_file(_PATH_SYSOPTIONS, privileged, 0, 1)
> || !options_from_user())
> exit(EXIT_OPTION_ERROR);
>
> which says, if we're not running as real uid root (never mind effective uid),
> bail out with an error message. In fact, the second argument (which is called
> "must_exist" in options.c) appears to be in error. Rather than root through
> the code, I bypassed this stretch and got reasonable behavior.

No. You've misread this section of code.

The fourth argument -- hard coded to 1 for /etc/ppp/options -- is what
tells the options-processing subsystem that this file always contains
privileged options, regardless of the user's privilege level.

I checked versions 2.3.3 through 2.4.0b2, and all of them have the
following line in main.c. (Versions at 2.2 and before handle options
rather differently.) I don't know what version you might be using,
but it looks to me like it's mangled.

if (!options_from_file(_PATH_SYSOPTIONS, !privileged, 0, 1)

The second argument (must_exist) is set to "!privileged" so that
non-root users may use pppd *only if* /etc/ppp/options exists. This
is a feature. You can restrict use of PPP to root by removing the
/etc/ppp/options file or permit ordinary users to use pppd by creating
this file. (Since ordinary users are not privileged, the must_exist
argument is set to 1 for them, and if the file doesn't exist, pppd
will exit with an error.)

Unfortunately, this feature isn't in the current man pages ...

--
James Carlson, Internet Engineering <james.d...@east.sun.com>
SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677

kis...@my-deja.com

unread,
Sep 1, 2000, 12:57:11 PM9/1/00
to
I got a similar error when I connect (over dialup) to my Linux box..
from minicom it drops me this:

atdt0,47811495
CONNECT/ARQ

Red Hat Linux release 6.1 (Cartman)
Kernel 2.2.12-20 on an i686


iis.argus-is.com.ar login: pepe
Password:
No directory /home/pepe!
Logging in with home = "/".
/usr/sbin/pppd: Can't open options file /home/pepe/.ppprc: Permission
denied

NO CARRIER

then, it terminate the connection. I have not configured the
/etc/ppp/option..where can i get a faq or document about it?

In article <odr97jy...@h006008986325.ne.mediaone.net>,


James Carlson <car...@workingcode.com> wrote:
> nos...@fastband.com (Dave) writes:
> > On 20 Aug 2000 03:04:11 GMT, Bill Unruh <un...@physics.ubc.ca>
wrote:

> > : Just put noauth into /etc/ppp/options ( making sure it is not user
> > : writable).
> >


> > As I said, depends upon the version.
>
> You did say that, but it's still not true. All options read from
> /etc/ppp/options, /etc/ppp/options.ttyname, and /etc/ppp/peers/name
> are always privileged. Options placed on the command line or in
> ~/.ppprc have the invoker's privilege. (Option files read by the
> "file" option have the same privilege level as the place where the
> option itself occurs.)
>
> --
> James Carlson
<car...@workingcode.com>

> "PPP Design and Debugging" ---
http://people.ne.mediaone.net/carlson/ppp
>


Sent via Deja.com http://www.deja.com/
Before you buy.

James Carlson

unread,
Sep 1, 2000, 1:24:57 PM9/1/00
to
kis...@my-deja.com writes:
> iis.argus-is.com.ar login: pepe
> Password:
> No directory /home/pepe!
> Logging in with home = "/".
> /usr/sbin/pppd: Can't open options file /home/pepe/.ppprc: Permission
> denied

That's a mess. It looks like the permissions on your home directory
(/home/pepe) are damaged. You should fix this.

> then, it terminate the connection. I have not configured the
> /etc/ppp/option..where can i get a faq or document about it?

The pppd options are documented in the man page. Do "man pppd".

--
James Carlson, Internet Engineering <james.d...@east.sun.com>
SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677

Second Edition now available - http://people.ne.mediaone.net/carlson/ppp

Bill Unruh

unread,
Sep 5, 2000, 12:29:16 PM9/5/00
to
In <8oon4r$v3i$1...@nnrp1.deja.com> kis...@my-deja.com writes:

]I got a similar error when I connect (over dialup) to my Linux box..


]from minicom it drops me this:

]atdt0,47811495
]CONNECT/ARQ

]Red Hat Linux release 6.1 (Cartman)
]Kernel 2.2.12-20 on an i686


]iis.argus-is.com.ar login: pepe
]Password:
]No directory /home/pepe!
]Logging in with home = "/".

You must read the stuff that the computer reports to you. This means
that you have not set up your account properly on that system. There is
no directory called /home/pepe on the machine-- the home directory
reported in the /etc/passwd file. Clean up this problem first.

]/usr/sbin/pppd: Can't open options file /home/pepe/.ppprc: Permission
]denied
No wonder since /home/pepe itself does not exist!

]>

0 new messages