This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Fwd: Bug#21810: libc6: rexec call dumps core with user="string" and password=NULL

   Date: Mon, 01 Nov 1999 10:39:26 +0000
   From: "Andrew Morton" <>

   Mark Kettenis wrote:
   >    From: Andreas Schwab <>
   >    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. (
   >From the manpage, VMS prompts.

   > Anyway, the issue has been discussed before [1].  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().

   It's broken.


   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? 
   It's silly.

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
it seems).

   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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]