linas@hparc0.HP.COM (Linas Petras) (03/31/91)
I am trying to run GDB-3.5 on SCO unix 3.2.2 and ever time I try and run a
test program ("hello world" type) I get an error message back from GDB
saying that permission is denied to exec /bin/sh.
I'm sure I have seen an answer to this somewhere, but I can't find the reference
anywhere in my archives. Can anyone tell me what the fix is ???? sef@kithrup.COM (Sean Eric Fagan) (04/01/91)
In article <3440016@hparc0.HP.COM> linas@hparc0.HP.COM (Linas Petras) writes: >I am trying to run GDB-3.5 on SCO unix 3.2.2 and ever time I try and run a >test program ("hello world" type) I get an error message back from GDB >saying that permission is denied to exec /bin/sh. The solution is to have a readable copy of the shell somewhere around. I copied /bin/sh to /usr/local/lib/gsh, and told gdb to use that instead of /bin/sh. gdb works just fine now. -- Sean Eric Fagan | "I made the universe, but please don't blame me for it; sef@kithrup.COM | I had a bellyache at the time." -----------------+ -- The Turtle (Stephen King, _It_) Any opinions expressed are my own, and generally unpopular with others.
enewton@uucp (Eric Newton x2092) (04/03/91)
> I am trying to run GDB-3.5 on SCO unix 3.2.2 and ever time I try and > run a test program ("hello world" type) I get an error message back > from GDB saying that permission is denied to exec /bin/sh. Try: $ su Password: # chmod uog+r /bin/sh # exit The normal permissions on /bin/sh leave it executable, but unreadable. Ick. I have no idea what this will do to undermine security. -Eric -- Remember to mail to: uunet.uu.net!srg!enewton "The more you complain, <or> newton@oswego.oswego.edu the longer God lets you <or> enewton@cme.nist.gov live."
src@scuzzy.in-berlin.de (Heiko Blume) (04/03/91)
linas@hparc0.HP.COM (Linas Petras) writes: >I am trying to run GDB-3.5 on SCO unix 3.2.2 and ever time I try and run a >test program ("hello world" type) I get an error message back from GDB >saying that permission is denied to exec /bin/sh. one must have read permission for /bin/sh... -- Heiko Blume <-+-> src@scuzzy.in-berlin.de <-+-> (+49 30) 691 88 93 [voice!] public UNIX source archive [HST V.42bis]: scuzzy Any ACU,f 38400 6919520 gin:--gin: nuucp sword: nuucp uucp scuzzy!/src/README /your/home
sralston@srwic.UUCP (Steve Ralston) (04/05/91)
linas@hparc0.HP.COM (Linas Petras) writes: >I am trying to run GDB-3.5 on SCO unix 3.2.2 and ever time I try and run a >test program ("hello world" type) I get an error message back from GDB >saying that permission is denied to exec /bin/sh. >I'm sure I have seen an answer to this somewhere, but I can't find the >reference anywhere in my archives. Can anyone tell me what the fix is ???? Simple... Just make sure and run gdb from /bin/sh... *Seriously* (I was surprised when I found out by accident) Gdb runs fine as root... hummmm.... My login shell was /bin/csh at the time... Here's my /usr/local/bin/gdb hack, er, FIX for gdb on SCO UNIX: =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= : SHELL=/bin/sh; export SHELL /usr/local/bin/gdb.real $* =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Wish I could tell you the root cause of the problem. All I can say is that I've had much shit break because of csh on SCO UNIX (make utility "weirdness" comes to mind). Another poster (Sean Eric Fagan) also mentioned that copying a READABLE copy of /bin/sh to /usr/local/lib/gsh (along with recompiling gdb, I assume) will solve this particular problem with gdb. FYI: All this was before I got industrious one nite and put /bin/ksh from 3.2v2 on a 3.2.1 (ODT1.0) system. Yeah, no job control in the 3.2.1 kernel, but job control kinda went out for me when multi-screens came in. On a related note, has anyone else seen something like: sh: can't exec /usr/bin/uuname during bootup on SCO UNIX (3.2.1, aka ODT1.0) coming out of /etc/rc? Drove me nuts for awhile until I changed the line causing this, from: /usr/lib/sendmail -q5m # this is really smail 3.1.20 to: /bin/su root -c '/usr/lib/sendmail -q5m' # this is really smail 3.1.20 Now, I don't get the message any more... BUT, the old "40 second pause until I put up the Password: prompt, you Jerk" problem has migrated from the initial multi-user login phase to a "40 second (bet you think your system just crashed, heh, heh)" delay during execution of /etc/rc during multi-user bootup. The 40 second delay stuff began the first bootup after installing TCP/IP. Can anybody offer explanations for: (1) Failed "exec's" on files that are executable by everyone (even when uid=0(root) gid=0(root)). or (2) The 40 second delay related to SCO TCP/IP Thanks in advance! -- Steve Ralston (sralston@srwic.UUCP || ..!uunet!ncrlnk!ncrwic!srwic!sralston) 235 N Zelta, Wichita, KS 67206