Debian Bug report logs - #21810
libc6: rexec call dumps core with user="string" and password=NULL

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Michael Meskes <meskes@topsystem.de>

To: submit@bugs.debian.org

Subject: netstd: rexec dumps core

Date: Tue, 28 Apr 1998 17:33:49 +0200

Package: netstd
Version: 3.05-1

What's happening here? I just get core cumps from rexec. strace says:

execve("/usr/bin/rexec", ["rexec", "localhost", "cat", ">remote_file; date"], [/* 51 vars */]) = 0
brk(0)                                  = 0x804b650
open("/etc/ld.so.preload", O_RDONLY)    = 3
fstat(3, {st_mode=0, st_size=0, ...})   = 0
mmap(0, 18, PROT_READ|PROT_WRITE, MAP_PRIVATE, 3, 0) = 0x4000c000
close(3)                                = 0
open("/lib/nfslock.so.0", O_RDONLY)     = 3
mmap(0, 4096, PROT_READ, MAP_PRIVATE, 3, 0) = 0x4000d000
munmap(0x4000d000, 4096)                = 0
mmap(0, 7876, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x4000d000
mprotect(0x4000e000, 3780, PROT_NONE)   = 0
mmap(0x4000e000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0x4000e000
close(3)                                = 0
munmap(0x4000c000, 18)                  = 0
open("/etc/ld.so.cache", O_RDONLY)      = 3
fstat(3, {st_mode=0, st_size=0, ...})   = 0
mmap(0, 23439, PROT_READ, MAP_PRIVATE, 3, 0) = 0x4000f000
close(3)                                = 0
open("/lib/libc.so.6", O_RDONLY)        = 3
mmap(0, 4096, PROT_READ, MAP_PRIVATE, 3, 0) = 0x4000c000
munmap(0x4000c000, 4096)                = 0
mmap(0, 670168, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40015000
mprotect(0x400a6000, 76248, PROT_NONE)  = 0
mmap(0x400a6000, 28672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x90000) = 0x400a6000
mmap(0x400ad000, 47576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x400ad000
close(3)                                = 0
personality(PER_LINUX)                  = 0
getpid()                                = 9508
brk(0)                                  = 0x804b650
brk(0x804b680)                          = 0x804b680
brk(0x804c000)                          = 0x804c000
open("/etc/nsswitch.conf", O_RDONLY)    = 3
fstat(3, {st_mode=0, st_size=0, ...})   = 0
mmap(0, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4000c000
read(3, "# /etc/nsswitch.conf\n#\n# Examp"..., 4096) = 406
brk(0x804d000)                          = 0x804d000
read(3, "", 4096)                       = 0
close(3)                                = 0
munmap(0x4000c000, 4096)                = 0
open("/lib/libnss_db.so.1", O_RDONLY)   = 3
mmap(0, 4096, PROT_READ, MAP_PRIVATE, 3, 0) = 0x4000c000
munmap(0x4000c000, 4096)                = 0
mmap(0, 20580, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x400b9000
mprotect(0x400bd000, 4196, PROT_NONE)   = 0
mmap(0x400bd000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x3000) = 0x400bd000
mmap(0x400be000, 100, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x400be000
close(3)                                = 0
open("/lib/libdb.so.2", O_RDONLY)       = 3
mmap(0, 4096, PROT_READ, MAP_PRIVATE, 3, 0) = 0x4000c000
munmap(0x4000c000, 4096)                = 0
mmap(0, 57232, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x400bf000
mprotect(0x400cc000, 3984, PROT_NONE)   = 0
mmap(0x400cc000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0xc000) = 0x400cc000
close(3)                                = 0
open("/lib/libnss_files.so.1", O_RDONLY) = 3
mmap(0, 4096, PROT_READ, MAP_PRIVATE, 3, 0) = 0x4000c000
munmap(0x4000c000, 4096)                = 0
mmap(0, 31936, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x400cd000
mprotect(0x400d4000, 3264, PROT_NONE)   = 0
mmap(0x400d4000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x6000) = 0x400d4000
close(3)                                = 0
open("/var/db/services.db", O_RDONLY)   = -1 ENOENT (No such file or directory)
open("/etc/services", O_RDONLY)         = 3
fcntl(3, F_GETFD)                       = 0
fcntl(3, F_SETFD, FD_CLOEXEC)           = 0
fstat(3, {st_mode=0, st_size=0, ...})   = 0
mmap(0, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4000c000
read(3, "# /etc/services:\n# $Id: service"..., 4096) = 4096
read(3, "p\t\t\t\t# UNIX Listserv\nulists"..., 4096) = 4096
close(3)                                = 0
munmap(0x4000c000, 4096)                = 0
socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 3
bind(3, {sin_family=AF_INET, sin_port=htons(5000), sin_addr=inet_addr("0.0.0.0")}, 16) = 0
gettimeofday({893777583, 591117}, NULL) = 0
getpid()                                = 9508
open("/etc/resolv.conf", O_RDONLY)      = 4
fstat(4, {st_mode=0, st_size=0, ...})   = 0
mmap(0, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4000c000
read(4, "domain topsystem.de\nnameserver "..., 4096) = 42
read(4, "", 4096)                       = 0
close(4)                                = 0
munmap(0x4000c000, 4096)                = 0
open("/etc/hosts", O_RDONLY)            = 4
fcntl(4, F_GETFD)                       = 0
fcntl(4, F_SETFD, FD_CLOEXEC)           = 0
fstat(4, {st_mode=0, st_size=0, ...})   = 0
mmap(0, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4000c000
read(4, "172.26.1.3\tgauss.topsystem.de g"..., 4096) = 262
close(4)                                = 0
munmap(0x4000c000, 4096)                = 0
open("/home/meskes/.netrc", O_RDONLY)   = 4
uname({sys="Linux", node="gauss", ...}) = 0
fstat(4, {st_mode=0, st_size=0, ...})   = 0
mmap(0, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4000c000
read(4, "#set auto-binary\n#set local-dir"..., 4096) = 2269
read(4, "", 4096)                       = 0
close(4)                                = 0
munmap(0x4000c000, 4096)                = 0
socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 4
connect(4, {sin_family=AF_INET, sin_port=htons(512), sin_addr=inet_addr("127.0.0.1")}, 16) = 0
socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 5
listen(5, 1)                            = 0
getsockname(5, {sin_family=AF_INET, sin_port=htons(20556), sin_addr=inet_addr("127.0.0.1")}, [16]) = 0
write(4, "20556\0", 6)                  = 6
accept(5, {sin_family=AF_INET, sin_port=htons(20562), sin_addr=inet_addr("127.0.0.1")}, [16]) = 6
close(5)                                = 0
--- SIGSEGV (Speicherzugriffsfehler) ---
+++ killed by SIGSEGV +++


Michael

-- System Information
Debian Release: 2.0 (frozen)
Kernel Version: Linux gauss 2.0.33 #2 Wed Dec 17 09:14:18 MEZ 1997 i686 unknown

Versions of the packages netstd depends on:
cpp	Version: 2.8.1-0.1
netbase	Version: 3.06-1
libc6	Version: 2.0.7pre3-1
libreadlineg2	Version: 2.1-9
ncurses3.4	Version: 1.9.9g-8

--- Begin /etc/exports (modified conffile)

--- End /etc/exports

Message #14 received at 21810@bugs.debian.org (full text, mbox, reply):

From: Herbert Xu <herbert@gondor.apana.org.au>

To: 4c@4c.com.au, 46142@bugs.debian.org

Cc: 21810@bugs.debian.org

Subject: Re: Bug#46142: rexec still does not look at .netrc

Date: Tue, 28 Sep 1999 14:20:46 +1000

severity 21810 important
quit

On Tue, Sep 28, 1999 at 11:47:55AM +1000, Daryl Radivojevic wrote:
> Package: rexec
> Version: 1.5-1
> 
> rexec does not look at the .netrc file at all. As stated in the man page
> rexec should
> look at the .netrc file in the users home directory to find a default login
> and password
> for the specified machine. But looking through the source code bug #34100
> left
> over from version 1.4 from the package is still not fixed. There is nothing
> in the
> source code that will look at the .netrc file.
> 
> Note 1: Red Hat has the identical problem (I do not know of other
> distributions).
> Note 2: I managed to fix the problem for myself by hacking into rexec.c and
> merging
> some of the code from the ftp code. (Ahhh.. the beauty of open source.)

OK.  What happened is that libc6 broke rexec(3) by not prompting when the
user/password is not set, then this was incorrectly fixed in rexec.  What
I'm going to do now is to restore the original rexec code and wait for the
libc6 maintainer to fix it.  This will have the side effect of rexec crashing
but maybe that'll at least get someone to write a patch for libc6 :)

There is already a bug report about this (#21810).  I'm going to raise the
severity because it causes rexec to be unusable in some circumstances.
-- 
Debian GNU/Linux 2.1 is out! ( http://www.debian.org/ )
Email:  Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Message #21 received at 21810@bugs.debian.org (full text, mbox, reply):

From: Raul Miller <raul@usatoday.com>

To: Herbert Xu <herbert@gondor.apana.org.au>, 21810@bugs.debian.org

Subject: Re: Bug#21810: Bug#46142: rexec still does not look at .netrc

Date: Tue, 28 Sep 1999 01:24:30 -0400

On Tue, Sep 28, 1999 at 02:20:46PM +1000, Herbert Xu wrote:
> OK. What happened is that libc6 broke rexec(3) by not prompting when
> the user/password is not set, then this was incorrectly fixed in
> rexec.

I can't find anything in the libc docs about prompting for rexec.

What is libc6 doing wrong?

-- 
Raul

Message #26 received at 21810@bugs.debian.org (full text, mbox, reply):

From: Herbert Xu <herbert@gondor.apana.org.au>

To: Raul Miller <raul@usatoday.com>

Cc: 21810@bugs.debian.org

Subject: Re: Bug#21810: Bug#46142: rexec still does not look at .netrc

Date: Tue, 28 Sep 1999 16:18:09 +1000

On Tue, Sep 28, 1999 at 01:24:30AM -0400, Raul Miller wrote:
> On Tue, Sep 28, 1999 at 02:20:46PM +1000, Herbert Xu wrote:
> > OK. What happened is that libc6 broke rexec(3) by not prompting when
> > the user/password is not set, then this was incorrectly fixed in
> > rexec.
> 
> I can't find anything in the libc docs about prompting for rexec.
> 
> What is libc6 doing wrong?

Historically the rexec(3) would prompt for the username/password if the
arguments were null.  libc6 changed this, i.e., it now segfaults rather
than prompting for them.

Indeed, if we wish to keep the netrc code in rexec as has always been the
case, then the only place to prompt for missing usernames/passwords is
in rexec(3) (or actually, ruserpass()).

You won't find anything in the docs because there simply isn't any :)
-- 
Debian GNU/Linux 2.1 is out! ( http://www.debian.org/ )
Email:  Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Message #29 received at 21810-forwarded@bugs.debian.org (full text, mbox, reply):

From: Joel Klecker <espy@debian.org>

To: libc-alpha@sourceware.cygnus.com

Cc: 21810-forwarded@bugs.debian.org

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

Date: Tue, 26 Oct 1999 00:43:47 -0700

More details are at: <http://www.debian.org/Bugs//db/21/21810.html>.

>Subject: Bug#21810: Bug#46142: rexec still does not look at .netrc
>Reply-To: Herbert Xu <herbert@gondor.apana.org.au>, 21810@bugs.debian.org
>Resent-From: Herbert Xu <herbert@gondor.apana.org.au>
>Resent-To: debian-bugs-dist@lists.debian.org
>Resent-CC: Debian GNU C Library Maintainers <debian-glibc@lists.debian.org>
>Resent-Date: Tue, 28 Sep 1999 06:33:01 GMT
>X-Debian-PR-Message: report 21810
>X-Debian-PR-Package: libc6
>X-Debian-PR-Keywords:
>X-Loop: owner@bugs.debian.org
>Date: Tue, 28 Sep 1999 16:18:09 +1000
>From: Herbert Xu <herbert@gondor.apana.org.au>
>To: Raul Miller <raul@usatoday.com>
>Cc: 21810@bugs.debian.org
>User-Agent: Mutt/0.95.7i
>X-Mailing-List: <debian-bugs-dist@lists.debian.org> archive/latest/50566
>X-Loop: debian-bugs-dist@lists.debian.org
>Resent-Sender: debian-bugs-dist-request@lists.debian.org
>Status:
>
>On Tue, Sep 28, 1999 at 01:24:30AM -0400, Raul Miller wrote:
>> On Tue, Sep 28, 1999 at 02:20:46PM +1000, Herbert Xu wrote:
>> > OK. What happened is that libc6 broke rexec(3) by not prompting when
>> > the user/password is not set, then this was incorrectly fixed in
>> > rexec.
>>
>> I can't find anything in the libc docs about prompting for rexec.
>>
>> What is libc6 doing wrong?
>
>Historically the rexec(3) would prompt for the username/password if the
>arguments were null.  libc6 changed this, i.e., it now segfaults rather
>than prompting for them.
>
>Indeed, if we wish to keep the netrc code in rexec as has always been the
>case, then the only place to prompt for missing usernames/passwords is
>in rexec(3) (or actually, ruserpass()).
>
>You won't find anything in the docs because there simply isn't any :)
>--
>Debian GNU/Linux 2.1 is out! ( http://www.debian.org/ )
>Email:  Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
>Home Page: http://gondor.apana.org.au/~herbert/
>PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-- 
Joel Klecker (aka Espy)       <URL:mailto:espy@debian.org>
Debian Package Maintainer for the GNU C Library.

Message #30 received at 21810-forwarded@bugs.debian.org (full text, mbox, reply):

From: Mark Kettenis <kettenis@wins.uva.nl>

To: espy@debian.org

Cc: libc-alpha@sourceware.cygnus.com, 21810-forwarded@bugs.debian.org

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

Date: Tue, 26 Oct 1999 19:17:16 +0200 (MET DST)

   Date: Tue, 26 Oct 1999 00:43:47 -0700
   From: Joel Klecker <espy@debian.org>

   >On Tue, Sep 28, 1999 at 01:24:30AM -0400, Raul Miller wrote:
   >> On Tue, Sep 28, 1999 at 02:20:46PM +1000, Herbert Xu wrote:
   >> > OK. What happened is that libc6 broke rexec(3) by not prompting when
   >> > the user/password is not set, then this was incorrectly fixed in
   >> > rexec.
   >>
   >> I can't find anything in the libc docs about prompting for rexec.
   >>
   >> What is libc6 doing wrong?
   >
   >Historically the rexec(3) would prompt for the username/password if the
   >arguments were null.  libc6 changed this, i.e., it now segfaults rather
   >than prompting for them.

Do you have any evidence that the statement about rexec asking for the
username/password is true?  Although the BSD man pages do indeed
mention that rexec() would do this, none of the BSD's derived from
BSD 4.2 (which according to the man page is the first version that has
rexec()) do implement this.  Since the code in glibc is derived
directly from BSD, it is no surprise that glibc doesn't do this
either.  So the whole issue appears to be a documentation bug on the
side of BSD.  There may be some reimplementations of rexec() around
that do ask for a password based on the BSD documentation,  but that's
not very relevant.  I think that there are a lot of cases where it is
unwanted.  As a principle, no library call should print anything
(except when that's the explicit purpose of the call of course), let
alone ask for input.

People that want the rexec to ask for a password, should implement
their own alternative.

Mark

Message #31 received at 21810-forwarded@bugs.debian.org (full text, mbox, reply):

From: Andreas Schwab <schwab@suse.de>

To: Mark Kettenis <kettenis@wins.uva.nl>

Cc: espy@debian.org, libc-alpha@sourceware.cygnus.com, 21810-forwarded@bugs.debian.org

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

Date: 26 Oct 1999 19:46:22 +0200

Mark Kettenis <kettenis@wins.uva.nl> writes:

|>    Date: Tue, 26 Oct 1999 00:43:47 -0700
|>    From: Joel Klecker <espy@debian.org>
|> 
|>    >On Tue, Sep 28, 1999 at 01:24:30AM -0400, Raul Miller wrote:
|>    >> On Tue, Sep 28, 1999 at 02:20:46PM +1000, Herbert Xu wrote:
|>    >> > OK. What happened is that libc6 broke rexec(3) by not prompting when
|>    >> > the user/password is not set, then this was incorrectly fixed in
|>    >> > rexec.
|>    >>
|>    >> I can't find anything in the libc docs about prompting for rexec.
|>    >>
|>    >> What is libc6 doing wrong?
|>    >
|>    >Historically the rexec(3) would prompt for the username/password if the
|>    >arguments were null.  libc6 changed this, i.e., it now segfaults rather
|>    >than prompting for them.
|> 
|> Do you have any evidence that the statement about rexec asking for the
|> username/password is true?

Solaris does actually implement it.

Andreas.

-- 
Andreas Schwab                                  "And now for something
SuSE Labs                                        completely different."
schwab@suse.de
SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg

Message #32 received at 21810-forwarded@bugs.debian.org (full text, mbox, reply):

From: Andreas Schwab <schwab@suse.de>

To: Mark Kettenis <kettenis@wins.uva.nl>

Cc: espy@debian.org, libc-alpha@sourceware.cygnus.com, 21810-forwarded@bugs.debian.org

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

Date: 26 Oct 1999 19:50:35 +0200

Mark Kettenis <kettenis@wins.uva.nl> writes:

|>    Date: Tue, 26 Oct 1999 00:43:47 -0700
|>    From: Joel Klecker <espy@debian.org>
|> 
|>    >On Tue, Sep 28, 1999 at 01:24:30AM -0400, Raul Miller wrote:
|>    >> On Tue, Sep 28, 1999 at 02:20:46PM +1000, Herbert Xu wrote:
|>    >> > OK. What happened is that libc6 broke rexec(3) by not prompting when
|>    >> > the user/password is not set, then this was incorrectly fixed in
|>    >> > rexec.
|>    >>
|>    >> I can't find anything in the libc docs about prompting for rexec.
|>    >>
|>    >> What is libc6 doing wrong?
|>    >
|>    >Historically the rexec(3) would prompt for the username/password if the
|>    >arguments were null.  libc6 changed this, i.e., it now segfaults rather
|>    >than prompting for them.
|> 
|> Do you have any evidence that the statement about rexec asking for the
|> username/password is true?

Both Solaris 5.5.1 and SunOS 4.1.4 implement it.

Andreas.

-- 
Andreas Schwab                                  "And now for something
SuSE Labs                                        completely different."
schwab@suse.de
SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg

Message #33 received at 21810-forwarded@bugs.debian.org (full text, mbox, reply):

From: Mark Kettenis <kettenis@wins.uva.nl>

To: schwab@suse.de

Cc: espy@debian.org, libc-alpha@sourceware.cygnus.com, 21810-forwarded@bugs.debian.org

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

Date: Wed, 27 Oct 1999 02:37:02 +0200 (CEST)

   From: Andreas Schwab <schwab@suse.de>
   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.

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().

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.

Mark

[1] http://sourceware.cygnus.com/ml/bug-glibc/1999-07/msg00085.html

Message #40 received at 21810@bugs.debian.org (full text, mbox, reply):

From: Herbert Xu <herbert@gondor.apana.org.au>

To: libc6@packages.debian.org, 21810@bugs.debian.org

Subject: Re: Processed:

Date: Wed, 27 Oct 1999 18:48:01 +1000

reassign 21810 libc6
quit

On Wed, Oct 27, 1999 at 04:33:05AM -0000, Debian Bug Tracking System wrote:
> 
> > reassign 21810 netstd
> Bug#21810: libc6: rexec call dumps core with user="string" and password=NULL
> Bug reassigned from package `libc6' to `netstd'.

This is not a bug in rexec.  It's in libc6.
-- 
Debian GNU/Linux 2.1 is out! ( http://www.debian.org/ )
Email:  Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Message #47 received at 21810@bugs.debian.org (full text, mbox, reply):

From: Joel Klecker <jk@espy.org>

To: 21810@bugs.debian.org, rexec@packages.debian.org

Cc: control@bugs.debian.org

Subject: Re: Processed:

Date: Wed, 27 Oct 1999 02:13:25 -0700

reassign 21810 rexec
thanks

At 18:48 +1000 1999-10-27, Herbert Xu wrote:
>reassign 21810 libc6
>quit
>
>On Wed, Oct 27, 1999 at 04:33:05AM -0000, Debian Bug Tracking System wrote:
>>
>> > reassign 21810 netstd
>> Bug#21810: libc6: rexec call dumps core with user="string" and password=NULL
>> Bug reassigned from package `libc6' to `netstd'.
>
>This is not a bug in rexec.  It's in libc6.

Upstream says it's not. See the current bug logs for #21810.
-- 
Joel Klecker (aka Espy)                    Debian GNU/Linux Developer
<URL:mailto:jk@espy.org>                 <URL:mailto:espy@debian.org>
<URL:http://web.espy.org/>               <URL:http://www.debian.org/>

Message #54 received at 21810@bugs.debian.org (full text, mbox, reply):

From: Herbert Xu <herbert@gondor.apana.org.au>

To: Joel Klecker <jk@espy.org>

Cc: 21810@bugs.debian.org

Subject: Re: Processed:

Date: Wed, 27 Oct 1999 21:02:05 +1000

severity 48446 important
merge 21810 48446
reassign 21810 libc6
quit

On Wed, Oct 27, 1999 at 02:13:25AM -0700, Joel Klecker wrote:
> >
> >This is not a bug in rexec.  It's in libc6.
> 
> Upstream says it's not. See the current bug logs for #21810.

Reading the logs, as well as the the past discussion referred to by
Mark Kettenis (in that thread, it seems that the people who replied to Andrew
Morton didn't actually use their brains), it seems that they're saying BSD's
rexec does not prompt.  Well a quick look at OpenBSD's rexec(3) manpage
indicates that it does prompt:

     The rexec() function looks up the host *ahost using gethostbyname(3),
     returning -1 if the host does not exist.  Otherwise *ahost is set to the
     standard name of the host.  If a username and password are both speci­
     fied, then these are used to authenticate to the foreign host; otherwise
     the environment and then the user's .netrc file in his home directory are
     searched for appropriate information.  If all this fails, the user is
     prompted for the information.

Anyway, let me explain why if rexec(1) (not rexec(3)) is going to call
rexec(3) and prompt according to BSD tradition, then the prompting has to
be done in rexec(3).  I've actually tried to do it outside, but failed.
That's before I even discovered #21810.

The prompting is only done when the necessary information cannot be found in
netrc.  Well, the code that searches netrc is in rexec(3).  So if rexec(1)
does the prompting, it must supplies rexec(3) with non-null arguments all
the time, effectively disabling the netrc feature.  If it supplies rexec(3)
with null arguments, then the latter must prompt.

That's why I think the people who replied to you and Andrew Morton didn't
actually spend the little time needed to think about this.  Also, the reason
we're complaining about this at all is because libc5 had the correct BSD
implementation.  The upgrade to libc6 broke rexec(1).

Based on the above, I believe I have enough reason to reassign this back.
I'm sorry that you have to deal with such unhelpful upstream people, but
what I'd do in this case is just fix it in Debian and send the patch upstream.
It doesn't really matter whether they fold it in or not since this section
of code is hardly ever touched anyway.

If you don't have time to construct the patch yourself (it should be as easy
as copying the relevant files out of libc5), I can do it for you.
-- 
Debian GNU/Linux 2.1 is out! ( http://www.debian.org/ )
Email:  Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Message #65 received at 21810@bugs.debian.org (full text, mbox, reply):

From: Joel Klecker <jk@espy.org>

To: Herbert Xu <herbert@gondor.apana.org.au>

Cc: 21810@bugs.debian.org

Subject: Re: Processed:

Date: Wed, 27 Oct 1999 06:30:54 -0700

At 21:02 +1000 1999-10-27, Herbert Xu wrote:
>Reading the logs, as well as the the past discussion referred to by
>Mark Kettenis (in that thread, it seems that the people who replied to Andrew
>Morton didn't actually use their brains), it seems that they're saying BSD's
>rexec does not prompt.  Well a quick look at OpenBSD's rexec(3) manpage
>indicates that it does prompt:
>
>     The rexec() function looks up the host *ahost using gethostbyname(3),
>     returning -1 if the host does not exist.  Otherwise *ahost is set to the
>     standard name of the host.  If a username and password are both speci-
>     fied, then these are used to authenticate to the foreign host; otherwise
>     the environment and then the user's .netrc file in his home directory are
>     searched for appropriate information.  If all this fails, the user is
>     prompted for the information.

The man page says that, but the code does no such thing. See for 
yourself: 
<http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libcompat/4.3/rexec.c?r 
ev=1.2>.

>Anyway, let me explain why if rexec(1) (not rexec(3)) is going to call
>rexec(3) and prompt according to BSD tradition, then the prompting has to
>be done in rexec(3).  I've actually tried to do it outside, but failed.
>That's before I even discovered #21810.

If it's tradition, why does no BSD implement the behavior? I've 
looked at 4.4BSD-Lite2 as well, its rexec(3) man page also says it 
prompts, and again the code does not.

>That's why I think the people who replied to you and Andrew Morton didn't
>actually spend the little time needed to think about this.  Also, the reason
>we're complaining about this at all is because libc5 had the correct BSD
>implementation.  The upgrade to libc6 broke rexec(1).

BSD doesn't have "the correct BSD" implementation either.

>Based on the above, I believe I have enough reason to reassign this back.
>I'm sorry that you have to deal with such unhelpful upstream people, but
>what I'd do in this case is just fix it in Debian and send the patch upstream.

I don't appreciate your characterizing glibc upstream as unhelpful.

>If you don't have time to construct the patch yourself (it should be as easy
>as copying the relevant files out of libc5), I can do it for you.

Don't waste the effort.
-- 
Joel Klecker (aka Espy)                    Debian GNU/Linux Developer
<URL:mailto:jk@espy.org>                 <URL:mailto:espy@debian.org>
<URL:http://web.espy.org/>               <URL:http://www.debian.org/>

Message #70 received at 21810@bugs.debian.org (full text, mbox, reply):

From: Martin Schulze <joey@finlandia.Infodrom.North.DE>

To: Joel Klecker <jk@espy.org>, 21810@bugs.debian.org

Cc: Herbert Xu <herbert@gondor.apana.org.au>

Subject: Re: Bug#21810: Processed:

Date: Wed, 27 Oct 1999 19:41:55 +0200

Joel Klecker wrote:
> >That's why I think the people who replied to you and Andrew Morton didn't
> >actually spend the little time needed to think about this.  Also, the reason
> >we're complaining about this at all is because libc5 had the correct BSD
> >implementation.  The upgrade to libc6 broke rexec(1).
> 
> BSD doesn't have "the correct BSD" implementation either.

Well, that's no reason why Linux (or Debian) must not follow the
documentation, right?  I would appreciate a solution, and just
thinking about backend and frontend I would believer that the
user program (rexec(1)) should prompt while the backend call
(rexec(3)) should be silent.

Regards,

	Joey

-- 
No question is too silly to ask, but, of course, some are too silly
to answer.   -- Perl book

Please always Cc to me when replying to me on the lists.

Message #75 received at 21810@bugs.debian.org (full text, mbox, reply):

From: Herbert Xu <herbert@gondor.apana.org.au>

To: Joel Klecker <jk@espy.org>

Cc: 21810@bugs.debian.org

Subject: Re: Processed:

Date: Thu, 28 Oct 1999 06:51:26 +1000

reassign 21810 libc6
quit

On Wed, Oct 27, 1999 at 06:30:54AM -0700, Joel Klecker wrote:
> 
> The man page says that, but the code does no such thing. See for 
> yourself: 
> <http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libcompat/4.3/rexec.c?r 
> ev=1.2>.

The code is not in rexec.c.  It's in ruserpass().

> >Anyway, let me explain why if rexec(1) (not rexec(3)) is going to call
> >rexec(3) and prompt according to BSD tradition, then the prompting has to
> >be done in rexec(3).  I've actually tried to do it outside, but failed.
> >That's before I even discovered #21810.
> 
> If it's tradition, why does no BSD implement the behavior? I've 
> looked at 4.4BSD-Lite2 as well, its rexec(3) man page also says it 
> prompts, and again the code does not.

Even if you refuse to do the prompt in rexec(3).  The segfault bug is still
in rexec(3).  If you read the code, you would've seen that rexec(3) calls
ruserpass() to do the netrc search if one of the arguments is null.  If netrc
doesn't contain the necessary information, the arguments are still null and
rexec(3) proceeds to segfault.  This bug is in rexec(3).  So I don't know
why you're reassigning it back.

> >That's why I think the people who replied to you and Andrew Morton didn't
> >actually spend the little time needed to think about this.  Also, the reason
> >we're complaining about this at all is because libc5 had the correct BSD
> >implementation.  The upgrade to libc6 broke rexec(1).
> 
> BSD doesn't have "the correct BSD" implementation either.

It's not about the correct behaviour now.  It's about fixing a null pointer
bug.
-- 
Debian GNU/Linux 2.1 is out! ( http://www.debian.org/ )
Email:  Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Message #80 received at 21810@bugs.debian.org (full text, mbox, reply):

From: Herbert Xu <herbert@gondor.apana.org.au>

To: Martin Schulze <joey@infodrom.north.de>, 21810@bugs.debian.org

Cc: Joel Klecker <jk@espy.org>

Subject: Re: Bug#21810: Processed:

Date: Thu, 28 Oct 1999 06:55:09 +1000

On Wed, Oct 27, 1999 at 07:41:55PM +0200, Martin Schulze wrote:
> 
> Well, that's no reason why Linux (or Debian) must not follow the
> documentation, right?  I would appreciate a solution, and just
> thinking about backend and frontend I would believer that the
> user program (rexec(1)) should prompt while the backend call
> (rexec(3)) should be silent.

rexec(1) can't prompt at the moment because the netrc search is done in
ruserpass() called by rexec(3).
-- 
Debian GNU/Linux 2.1 is out! ( http://www.debian.org/ )
Email:  Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Message #87 received at 21810@bugs.debian.org (full text, mbox, reply):

From: Adrian Bridgett <adrian.bridgett@iname.com>

To: 21810@bugs.debian.org

Subject: Re: Bug#21810: Processed:

Date: Fri, 29 Oct 1999 00:12:52 +0100

On Thu, Oct 28, 1999 at 06:55:09 +1000 (+0000), Herbert Xu wrote:
> On Wed, Oct 27, 1999 at 07:41:55PM +0200, Martin Schulze wrote:
> > 
> > Well, that's no reason why Linux (or Debian) must not follow the
> > documentation, right?  I would appreciate a solution, and just
> > thinking about backend and frontend I would believer that the
> > user program (rexec(1)) should prompt while the backend call
> > (rexec(3)) should be silent.
> 
> rexec(1) can't prompt at the moment because the netrc search is done in
> ruserpass() called by rexec(3).

and rexec(3) carries on regardless of whether ruserpass() found something or
not :-(

I would have thought something like this was reasonable to both parties:

rexec(1)
   rexec(3)
     ruserpass
    (return "no entry")
   (return "no entry")
prompt user

I can understand that the glibc developers don't want to do the prompting,
but it's unacceptable for either .netrc to be useless or for rexec to
segfault.  The only other app that does this is netscape (and at least
that's not ridiculously simple to trigger).

Adrian

email: adrian.bridgett@iname.com,    http://www.poboxes.com/adrian.bridgett
Windows NT - Unix in beta-testing.   PGP key available on public key servers
Debian GNU/Linux  -*-   because I'm allergic to Prozac   -*-  www.debian.org

Message #88 received at 21810-forwarded@bugs.debian.org (full text, mbox, reply):

From: "Andrew Morton" <morton@nortelnetworks.com>

To: Mark Kettenis <kettenis@wins.uva.nl>

Cc: schwab@suse.de, espy@debian.org, libc-alpha@sourceware.cygnus.com, 21810-forwarded@bugs.debian.org

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

Date: Mon, 01 Nov 1999 10:39:26 +0000

Mark Kettenis wrote:
> 
>    From: Andreas Schwab <schwab@suse.de>
>    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 [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.

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.  

> 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.


I agree that popping up a prompt from within rexec() is rather
obnoxious, but that's the API. Caveat emptor.  Pass in a user/pass to
prevent it, just as you would to prevent a segfault from the GNU
implementation.



Semi-OnT:

Please be aware that there's another problem with this stuff:


In the wire protocol for rexec the client sends down a port number. 
This port represents the backchannel upon which the client is receiving
stderr output.  The server attempts to open that port on the client
*prior to authentication*.

Some time ago some bright spark realised that this could be used for
indirect portscanning and an attempt was made to change the wire
protocol.  The backchannel is only opened *after authentication*. 
Current redhat rexecd's are done this way.  Unfortunately:

- The wire protocol changes were not made to the client end (glibc).

- Consequently all Linux rexecd's can deadlock.  'rexec -a' is the
workaround.

- The fix is *not* to fix the client because Linux then won't work with
other unixes.

- The fix is to verify (within rexecd) that the connected-to port is not
privileged.  If it is privileged, or if the connection to the client is
refused, drop a security log amd bale.

- RedHat and variants will cause extra pain because their rexecd's vary
from the upstream versions (they've added PAM).


I was going to fix all this up mid-year, but for obvious reasons I've
lost interest.

Message #89 received at 21810-forwarded@bugs.debian.org (full text, mbox, reply):

From: Mark Kettenis <kettenis@wins.uva.nl>

To: morton@nortelnetworks.com

Cc: schwab@suse.de, espy@debian.org, libc-alpha@sourceware.cygnus.com, 21810-forwarded@bugs.debian.org

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

Date: Mon, 1 Nov 1999 12:45:36 +0100 (MET)

   Date: Mon, 01 Nov 1999 10:39:26 +0000
   From: "Andrew Morton" <morton@nortelnetworks.com>

   Mark Kettenis wrote:
   > 
   >    From: Andreas Schwab <schwab@suse.de>
   >    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 [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.

Yes.

   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.

Mark

Message #90 received at 21810-forwarded@bugs.debian.org (full text, mbox, reply):

From: "Andrew Morton" <morton@nortelnetworks.com>

To: Mark Kettenis <kettenis@wins.uva.nl>

Cc: schwab@suse.de, espy@debian.org, libc-alpha@sourceware.cygnus.com, 21810-forwarded@bugs.debian.org

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

Date: Mon, 01 Nov 1999 13:36:31 +0000

Mark Kettenis wrote:
> 
> One should probably use rcmd() instead.

mmm...  Requires root though.

> If you really want to use rexec() you'll have to do the .netrc parsing
> yourself, ...

Oh I'm OK - I just make sure .netrc is valid.  If it isn't I remove
./core and try again!

But right now, /usr/bin/rexec can drop core in surprising ways and
nobody is fixing it.  At the risk of quoting myself: "It's all a bit of
a mess".

At the least I suggest rexec(3) be taught to not dereference NULL under
these circumstances.


--- rexec.c     Thu Jul 16 15:45:29 1998
+++ new-rexec.c Tue Nov  2 00:34:34 1999
@@ -137,6 +137,9 @@
                }
                *fd2p = s3;
        }
+
+       if (name == 0)
+               goto bad;
        (void) __write(s, name, strlen(name) + 1);
        /* should public key encypt the password here */
        (void) __write(s, pass, strlen(pass) + 1);

Send a report that this bug log contains spam.