Red Hat Bugzilla – Bug 50076
rexec() cores when given a NULL password argument
Last modified: 2016-11-24 07:19:36 EST
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.
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
Segmentation fault (core dumped)
Expected Results: ./test2 dsn1
void err(char *msg);
main(int argc, char **argv)
char *host, msg;
struct servent *servent;
int sock, sig=0;
host = (char *)malloc(100*sizeof(char));
if(argc > 1) strcpy(host,argv);
servent = getservbyname("exec", "tcp");
port = ntohs(servent->s_port);
sock = rexec(&host, servent->s_port, "indexrlm", NULL, "hostname", &sig);
if(sock == -1) err("rexec failed");
fp = fdopen(sock, "r");
if(fp == NULL) err("fdopen failed");
while(fgets(msg, 200, fp) != NULL)
void err(char *msg)
Created attachment 25087 [details]
test c program for rexec problem
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
Try this on RHL9. I don't remember anymore whether we explicitly changed the
glibc code but your test program definitely doesn't crash.
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
Program received signal SIGSEGV, Segmentation fault.
0x400a5133 in strlen () from /lib/i686/libc.so.6
#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
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.
No reply in almost 6 months. Closing as NOTABUG.