Bug 50076 - rexec() cores when given a NULL password argument
rexec() cores when given a NULL password argument
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: glibc (Show other bugs)
7.1
alpha Linux
medium Severity medium
: ---
: ---
Assigned To: Phil Knirsch
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-07-26 11:41 EDT by Harry E. Turnbull
Modified: 2016-11-24 07:19 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-10-03 05:29:50 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
test c program for rexec problem (942 bytes, text/plain)
2001-07-26 11:44 EDT, Harry E. Turnbull
no flags Details

  None (edit)
Description Harry E. Turnbull 2001-07-26 11:41:10 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.76C-SGI [en] (X11; I; IRIX64 6.5 IP26)

Description of problem:
Rexec() cores when called with a NULL argument for password. This should be
the indication that rexec is to use the users environment (.netrc, etc.)
Also, the man page for rexec is missing.

How reproducible:
Always

Steps to Reproduce:
1.See attached example program
2.Actual results are when passed a NULL arg for password
3.Expected results are what should happen, also when passed an actual
string containing the users password
	

Actual Results:  ./test2 dsn1
dsn1 512
Segmentation fault (core dumped)

Expected Results:  ./test2 dsn1
dsn1 512
rexec done
rexec succeeded
fdopen succeeded
dsn1



Additional info:

include <sys/types.h>
#include <sys/socket.h>
#include <sys/ioctl.h>
#include <netinet/in.h>
#include <netdb.h>
#include <stdio.h>
#include <signal.h>
#include <math.h>

void err(char *msg);

main(int argc, char **argv)
{
  char *host, msg[200];
  struct servent *servent;
  int port;
  FILE *fp;
  int sock, sig=0;

  host = (char *)malloc(100*sizeof(char));
  strcpy(host, "DS20E");
  if(argc > 1) strcpy(host,argv[1]);
  servent = getservbyname("exec", "tcp");
  port = ntohs(servent->s_port);
  printf("%s %d\n",host,port);
  sock = rexec(&host, servent->s_port, "indexrlm", NULL, "hostname", &sig);
  printf("rexec done\n");
  if(sock == -1) err("rexec failed");
  printf("rexec succeeded\n");

  sleep(1);
  fp = fdopen(sock, "r");
  if(fp == NULL) err("fdopen failed");
  printf("fdopen succeeded\n");

  while(fgets(msg, 200, fp) != NULL)
      puts(msg);

}

void err(char *msg)
{
  perror("");
  printf("%s\n", msg);
  exit(1);
}
Comment 1 Harry E. Turnbull 2001-07-26 11:44:34 EDT
Created attachment 25087 [details]
test c program for rexec problem
Comment 2 Phil Knirsch 2001-07-31 10:50:17 EDT
OK, i studied the problem for a while. The problem actually is rooted in either

a) Wrong usage of the rexec() library call (for which we unfortunately don't
have any manpages or documentation online anymore)

b) Generally a problem with glibc resp. the rexec() call in it. The rexec
command that is part of the rsh package works as it is (not necessarily how the
manpage describes it with the $HOME/.netrc file, but thats a different story ;).

So i am reassigning it to the glibc package in any case as the rexec() call is
not to be found in the rsh package.

I will fix the missing manpage thing though, as it is really a bug in the
Makefile of rexec.

Read ya, Phil
Comment 3 Ulrich Drepper 2003-04-21 21:58:34 EDT
Try this on RHL9.  I don't remember anymore whether we explicitly changed the
glibc code but your test program definitely doesn't crash.
Comment 4 Phil Knirsch 2003-04-22 08:01:07 EDT
I just tried that test application again on my freshly installed RHL 9 and it
still segfaults for me. Here the gdb output:

[pknirsch@hamburg pknirsch]$ gdb ./a.out 
GNU gdb Red Hat Linux (5.3post-0.20021129.18rh)
Copyright 2003 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu"...
(gdb) run hamburg
Starting program: /mnt/stgt/home/devel/pknirsch/a.out hamburg
hamburg 512

Program received signal SIGSEGV, Segmentation fault.
0x400a5133 in strlen () from /lib/i686/libc.so.6
(gdb) where
#0  0x400a5133 in strlen () from /lib/i686/libc.so.6
#1  0x4012574b in rexec_af () from /lib/i686/libc.so.6
#2  0x401259bc in rexec () from /lib/i686/libc.so.6
#3  0x080486af in main (argc=2, argv=0xbfffda84) at y.c:26
#4  0x40040877 in __libc_start_main () from /lib/i686/libc.so.6

If you need any more output let me know.

Read ya, Phil
Comment 5 Ulrich Drepper 2003-04-23 03:42:08 EDT
In any case, the code we use is the original BSD code.  This is how the function
got defined.  It is what people have to live with.  I don't know where this
assumption that a NUL pointer has a special meaning comes from, but it surely is
historically wrong and unless some very good justification is presented I'll not
change a thing.
Comment 6 Ulrich Drepper 2003-10-03 05:29:50 EDT
No reply in almost 6 months.  Closing as NOTABUG.

Note You need to log in before you can comment on or make changes to this bug.