Your message dated Thu, 4 Jun 2009 10:37:35 +0200
with message-id <[email protected]>
and subject line Re: Bug#527554: pppd noauth required to get pppd working on
wired boxes
has caused the Debian Bug report #527554,
regarding pppd wrongly check if a route exist to peer making noauth option
mandatory for non-root users
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
527554: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=527554
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: ppp
Version: 2.4.4rel-10.1
Severity: normal
I am a 56k modem user trying to figure out why he is getting:
May 7 22:42:11 Arcturus pppd[4808]: The remote system is required to
authenticate itself
May 7 22:42:11 Arcturus pppd[4808]: but I couldn't find any suitable secret
(password) for it to use to do so.
May 7 22:42:11 Arcturus pppd[4808]: (None of the available passwords would let
it use an IP address.)
According to man pppd:
The default behaviour of pppd is to allow an unauthenticated peer to
use a given IP address only if the system does not already have a route
to that IP address. For example, a system with a permanent connection
to the wider internet will normally have a default route, and thus all
peers will have to authenticate themselves in order to set up a connec‐
tion. On such a system, the auth option is the default. On the other
hand, a system where the PPP link is the only connection to the inter‐
net will not normally have a default route, so the peer will be able to
use almost any IP address without authenticating itself.
So, as there is not supposed to be a route to my ISP, it seems wrong that I get:
"The remote system is required to authenticate itself"
So I downloaded source of ppp and begin looking inside the archive:
p...@arcturus:~/ppp-2.4.4rel/upstream/tarballs$ ls -lh
total 680K
-rw-r--r-- 1 paul paul 673K jun 27 2006 ppp-2.4.4.tar.gz
In auth.c there is:
void
auth_check_options()
{
lcp_options *wo = &lcp_wantoptions[0];
int can_auth;
int lacks_ip;
/* Default our_name to hostname, and user to our_name */
if (our_name[0] == 0 || usehostname)
strlcpy(our_name, hostname, sizeof(our_name));
if (user[0] == 0)
strlcpy(user, our_name, sizeof(user));
/*
* If we have a default route, require the peer to authenticate
* unless the noauth option was given or the real user is root.
*/
if (!auth_required && !allow_any_ip && have_route_to(0) && !privileged) {
auth_required = 1;
default_auth = 1;
}
/* If we selected any CHAP flavors, we should probably negotiate it. :-) */
if (wo->chap_mdtype)
wo->neg_chap = 1;
/* If authentication is required, ask peer for CHAP, PAP, or EAP. */
if (auth_required) {
allow_any_ip = 0;
if (!wo->neg_chap && !wo->neg_upap && !wo->neg_eap) {
wo->neg_chap = chap_mdtype_all != MDTYPE_NONE;
wo->chap_mdtype = chap_mdtype_all;
wo->neg_upap = 1;
wo->neg_eap = 1;
}
} else {
wo->neg_chap = 0;
wo->chap_mdtype = MDTYPE_NONE;
wo->neg_upap = 0;
wo->neg_eap = 0;
}
/*
* Check whether we have appropriate secrets to use
* to authenticate the peer. Note that EAP can authenticate by way
* of a CHAP-like exchanges as well as SRP.
*/
lacks_ip = 0;
can_auth = wo->neg_upap && (uselogin || have_pap_secret(&lacks_ip));
if (!can_auth && (wo->neg_chap || wo->neg_eap)) {
can_auth = have_chap_secret((explicit_remote? remote_name: NULL),
our_name, 1, &lacks_ip);
}
if (!can_auth && wo->neg_eap) {
can_auth = have_srp_secret((explicit_remote? remote_name: NULL),
our_name, 1, &lacks_ip);
}
if (auth_required && !can_auth && noauth_addrs == NULL) {
if (default_auth) {
option_error(
"By default the remote system is required to authenticate itself");
option_error(
"(because this system has a default route to the internet)");
} else if (explicit_remote)
option_error(
"The remote system (%s) is required to authenticate itself",
remote_name);
else
option_error(
"The remote system is required to authenticate itself");
option_error(
"but I couldn't find any suitable secret (password) for it to use to do so.");
if (lacks_ip)
option_error(
"(None of the available passwords would let it use an IP address.)");
exit(1);
}
Please concentrate on: if (!auth_required && !allow_any_ip && have_route_to(0)
&& !privileged) {
more precisely on have_route_to(0)
In sys-linux.c we have the implementation of have_route that have no special
code for 0 value:
/*
* have_route_to - determine if the system has any route to
* a given IP address. `addr' is in network byte order.
* Return value is 1 if yes, 0 if no, -1 if don't know.
* For demand mode to work properly, we have to ignore routes
* through our own interface.
*/
int have_route_to(u_int32_t addr)
{
struct rtentry rt;
int result = 0;
if (!open_route_table())
return -1; /* don't know */
while (read_route_table(&rt)) {
if ((rt.rt_flags & RTF_UP) == 0 || strcmp(rt.rt_dev, ifname) == 0)
continue;
if ((addr & SIN_ADDR(rt.rt_genmask)) == SIN_ADDR(rt.rt_dst)) {
result = 1;
break;
}
}
close_route_table();
return result;
}
Elsewhere in auth.c, there is an other use of have_route:
/*
* auth_ip_addr - check whether the peer is authorized to use
* a given IP address. Returns 1 if authorized, 0 otherwise.
*/
int
auth_ip_addr(unit, addr)
int unit;
u_int32_t addr;
{
int ok;
/* don't allow loopback or multicast address */
if (bad_ip_adrs(addr))
return 0;
if (allowed_address_hook) {
ok = allowed_address_hook(addr);
if (ok >= 0) return ok;
}
if (addresses[unit] != NULL) {
ok = ip_addr_check(addr, addresses[unit]);
if (ok >= 0)
return ok;
}
if (auth_required)
return 0; /* no addresses authorized */
return allow_any_ip || privileged || !have_route_to(addr);
}
Which I believe test for the last (4th) column (authorized IP address) of
/etc/ppp/pap-secrets... and similar files.
Not sure how this is relevant info...
The idea is that have_route_to(0) looks wrong to me... but I don't know by what
it should be replaced.
I pretend I should not need to use noauth option in kppp-options for an ISP.
-- System Information:
Debian Release: squeeze/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.6.26-2-686 (SMP w/1 CPU core)
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages ppp depends on:
ii libc6 2.9-4 GNU C Library: Shared libraries
ii libpam-modules 1.0.1-9 Pluggable Authentication Modules f
ii libpam-runtime 1.0.1-9 Runtime support for the PAM librar
ii libpam0g 1.0.1-9 Pluggable Authentication Modules l
ii libpcap0.8 1.0.0-1 system interface for user-level pa
ii netbase 4.34 Basic TCP/IP networking system
ii procps 1:3.2.7-11 /proc file system utilities
ppp recommends no packages.
Versions of packages ppp suggests:
ii iptables 1.4.3.2-2 administration tools for packet fi
-- no debconf information
--- End Message ---
--- Begin Message ---
On Jun 04, Ken Chase <[email protected]> wrote:
> Anyone who is wired to a network already will confusingly not be able to use
> PPP at all. This is a more serious bug than normal priority. The person who
People will need to RTFM, yes.
> Not sure of the rationale behind the code as it is now - most ppp client boxen
It's called "security".
--
ciao,
Marco
signature.asc
Description: Digital signature
--- End Message ---
