The noshell package in Debian Etch4.0 includes the useful "runas"
   tool that allows root to easily execture processes as
   any uid/gid/umask/chroot combination regardless of that
   uid/gid existing or having a valid shell.

Unfortunately as far as I can tell runas consistently fails
   on (at least) amd64 archituctire, but consistently works
   on i386 architecture.

Note this is version 4.0.11-4 and appears to be unchanged in
   lenny/sid.

The "runas" program will simply segfault in all of my experiments
   on multiple Debian Etch4.0 amd64 archicture systems.

I would appreciate others confirming this problem...
E.g. try to "runas 1000 1000 0022 /bin/bash" from root.

What debugging information should I collect etc.?
Thankyou in advance,

"enyc" <enyc@evtech.org>






Workarounds include:-

* install "ia32-libs" and extract the i386 version of noshell
   Debian package, use that "runas" binary.

* Use the following c-program (does not do chroot/umask):-

#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
main(int argc,char *argv[]) {
         int x,size;
         unsigned char *argl;
         argl=malloc(0);
         setuid(atoi(argv[1]));
         setgid(atoi(argv[2]));
         for(x=3,size=0;x<argc;x++) {
                 argl=realloc(argl,size+strlen(argv[x]));
                 strcpy(argl+size,*(argv+x));
                 size+=strlen(argv[x])+1;
                 *(argl+size-1)=' ';
         }
         printf("uid:%d euid:%d\n",getuid(),geteuid());
         printf("Running %s\n",argl);
         printf("exit:%d\n",system(argl));
}

Hello,
just tried to reproduce this crash.


I got following call stack in gdb with original packages:
(gdb) bt
#0  0x00002b57561a5c86 in strtouq () from /lib/libc.so.6
#1  0x00002b57561a3712 in atoi () from /lib/libc.so.6
#2  0x000000000045f5fe in dgettext ()
#3  0x0000000000405778 in __libc_start_main ()


When rebuilding just noshell:
(gdb) bt
#0  0x00002ad26562fc86 in strtouq () from /lib/libc.so.6
#1  0x00002ad26562d712 in atoi () from /lib/libc.so.6
#2  0x000000000045f67e in main (argc=5, argv=0x7fff456d13f8, envp=0x7fff456d1428) at runas.c:98


When even rebuilding glibc:

Program received signal SIGSEGV, Segmentation fault.
*__GI_____strtol_l_internal (nptr=0x7fff0a04fee6 "1000", endptr=0x0, base=10, group=0, loc=0x0) at ../sysdeps/generic/strtol_l.c:239
239       struct locale_data *current = loc->__locales[LC_NUMERIC];

(gdb) bt
#0  *__GI_____strtol_l_internal (nptr=0x7fff0a04fee6 "1000", endptr=0x0, base=10, group=0, loc=0x0) at ../sysdeps/generic/strtol_l.c:239
#1  0x00002ac5a0cae712 in atoi (nptr=0x7fff0a04fee6 "1000") at ../stdlib/stdlib.h:333
#2  0x000000000045f67e in main (argc=5, argv=0x7fff0a04dd78, envp=0x7fff0a04dda8) at runas.c:98


It might be related to the link command:
  gcc  -o runas /usr/lib/libc.a  -dn stubs.o runas.o


The link command seems to do dynamic linking but /usr/lib/libc.a seems
to be the static library judging from the size.

So either command produces an working executable:
    gcc -static -o runas /usr/lib/libc.a            -dn stubs.o runas.o
    gcc         -o runas /usr/lib/libc_nonshared.a  -dn stubs.o runas.o
    gcc         -o runas                            -dn stubs.o runas.o


At least Squeeze contains a Makefile.linux that got
the "/usr/lib/libc.a" commented out [1] [2].

So this bug can probably be marked as done.


Kind regards,
Bernhard


[1] https://sources.debian.org/src/titantools/4.0.11-4/Makefile.linux/
[2] https://sources.debian.org/src/titantools/4.0.11+notdfsg1-2/Makefile.linux/


PS.: Was fun, but is there no automatic bug closing when the
     release, the bug got reported against, is getting unsupported?