This is the mail archive of the
mailing list for the glibc project.
Re: Fwd: Bug#21810: libc6: rexec call dumps core with user="string" and password=NULL
- To: morton at nortelnetworks dot com
- Subject: Re: Fwd: Bug#21810: libc6: rexec call dumps core with user="string" and password=NULL
- From: Mark Kettenis <kettenis at wins dot uva dot nl>
- Date: Mon, 1 Nov 1999 12:45:36 +0100 (MET)
- CC: schwab at suse dot de, espy at debian dot org, libc-alpha at sourceware dot cygnus dot com, 21810-forwarded at bugs dot debian dot org
- References: <email@example.com> <199910261717.TAA21188@landau.wins.uva.nl> <firstname.lastname@example.org> <199910270037.CAA00259@delius.kettenis.local> <381D6DDE.B829735B@asiapacificm01.nt.com>
Date: Mon, 01 Nov 1999 10:39:26 +0000
From: "Andrew Morton" <email@example.com>
Mark Kettenis wrote:
> From: Andreas Schwab <firstname.lastname@example.org>
> Date: 26 Oct 1999 19:50:35 +0200
> Both Solaris 5.5.1 and SunOS 4.1.4 implement it.
> Well, I would certainly call SunOS 4 historic by now.
SunOS 5.6 prompts.
HPUX 10.20 prompts.
AIX 4.1.5 prompts.
Linux libc5 prompts. (http://www.uow.edu.au/~andrewm/ruserpass.c)
>From the manpage, VMS prompts.
> Anyway, the issue has been discussed before . Ulrich thinks
> we should stay with the BSD 4.4 implementation, and I agree with him.
> It's more or less the reference standard for rexec().
As it stands, this bug makes rexec(3) with NULL user/pass quite, quite
useless. This is because it has two possible behaviours:
1: A match is found in .netrc: rexec(3) uses it
2: No match is found in .netrc: rexec(3) segfaults.
How can you possibly use this, without having earlier called
getuserpass() to determine whether or not rexec(3) is going to core?
You cannot call rexec with a NULL pointer for any of its arguments,
except for the FD2P argument. Yes it is a wee bit silly that the
routine seems to do .netrc processing but in fact doesn't, but that's
how BSD has done this for quite some time now (at least since 4.3 as
Either fix the bug or go incompatible and handle the null return from
getuserpass() to avoid the segfault. Bug-for-bug compatibility with BSD
doesn't seem pointful.
The only reason for prividing rexec() is compatibility with
BSD. As you admit below there are serious security problems with the
rexec service. If we `fix' the bug we would actually encourage
clueless users to use this call. One should probably use rcmd() instead.
> Also note that rexec() is considered to be pretty dangerous. FreeBSD
> and NetBSD only offer it for compatibility with BSD 4.4, and
> reccommend using another mechanism.
For a trusted LAN environment, behind a firewall, with many Unix
variants, none of which ship SSH: it's very useful.
If you really want to use rexec() you'll have to do the .netrc parsing
yourself, and make sure that rexec() is passed a proper name and
password. Ripping the ruserpass code out of the BSD ftp program will
probably do what you want.