root@bu-cs.UUCP (Barry Shein) (09/23/85)
A gotcha in the shell that almost caused me further permanent brain-damage: Not Necessarily a Description: /bin/sh in SYSVR2 will look for the character 'r' *anywhere* in it's argv[0] when it starts up and, upon finding one, will run in restricted mode. Not Necessarily a Repeat-by: Write a program which forks off a shell with it's stdin/stdout/stderr attached to pipes, decide to put a different name and the file name from the command line the parent program got as a string in argv[0] for the exec() so it looks pretty when someone 'ps's us. Watch user's complain as it mysteriously fails and does strange things for some commands passed to it depending on the original file name given to the parent. Begin babbling incoherently till you start to see the reason why. This is especially fun if it's an oft run system command and not your program to start with and if the source is >25,000 lines of code and sdb keeps core-dumping when you try to trace things. Not Necessarily a Fix: Don't monkey around with argv[0] when starting up a shell, certainly don't put arbitrary user text into argv[0] or a fortune or some such, better to just let it be "sh" if that's what you meant. -Barry Shein, Boston University Not Necessarily a Quote: "And I alone survived to tell this tale"
guy@sun.uucp (Guy Harris) (09/24/85)
> /bin/sh in SYSVR2 will look for the character 'r' *anywhere* in it's > argv[0] when it starts up and, upon finding one, will run in restricted > mode. Some version of the Bourne shell (I think it was the one that results from applying all the changes Arnold Robbins posted) specifically checks for "rsh" being the basename of argv[0]. Any other check is incorrect; the "if (strchr(argv[0], 'r') != NULL)" check is bogus and the result of laziness. The fix is straightforward. Guy Harris
wcs@ho95e.UUCP (Bill.Stewart.4K435.x0705) (09/24/85)
> A gotcha in the shell that almost caused me further permanent brain-damage: > > Not Necessarily a Description: > > /bin/sh in SYSVR2 will look for the character 'r' *anywhere* in it's > argv[0] when it starts up and, upon finding one, will run in restricted > mode. > ............... > -Barry Shein, Boston University Hmmm.. it does seem to do that on my 3B20. $ cp /bin/sh braindamage $ braindamage $ >junk junk: restricted So I tried it with ksh (the Korn Shell), and I didn't have this problem. -- ## Bill Stewart, AT&T Bell Labs, Holmdel NJ 1-201-949-0705 ihnp4!ho95c!wcs
root@bu-cs.UUCP (Barry Shein) (09/28/85)
Re: an 'r' anywhere in argv[0] will cause sh (SYSV) to run restricted I have been told by ATTIS that this is considered a bug and will be fixed in a future release. So I guess it's Not Necessarily Not Necessarily a bug :-) Thank you ATTIS (and Guy Harris for pointing the same way.) -Barry Shein, Boston University P.S. that is, you can fix your shell or at least consider workarounds temporary (#ifdef NOTNECESSARILY....) The shell fix is trivial (if you have sources.)
mikel@codas.UUCP (Mikel Manitius) (10/04/85)
> Re: an 'r' anywhere in argv[0] will cause sh (SYSV) to run restricted > > I have been told by ATTIS that this is considered a bug and will be > fixed in a future release. So I guess it's Not Necessarily Not Necessarily > a bug :-) Thank you ATTIS (and Guy Harris for pointing the same way.) > > -Barry Shein, Boston University > > P.S. that is, you can fix your shell or at least consider workarounds > temporary (#ifdef NOTNECESSARILY....) The shell fix is trivial (if you > have sources.) Apparently someone was too lazy to scan only the last word of argv[0] (a word being delimiterd by '/') for an 'r'. I don't see where someone would really want to make another copy of sh, although /usr/rbin/sh is a possibility. -- ======= Mikel Manitius ==----===== AT&T ...!{ihnp4!}codas!mikel ==------===== Information Systems (305) 869-2462 ===----====== SDSS Regional Support AT&T-IS ETN: 755 =========== Altamonte Springs, FL My opinions are my own. =======
gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (10/09/85)
> ... I don't see where someone > would really want to make another copy of sh, although /usr/rbin/sh is > a possibility. argv[0] has no necessary relation to a pathname of the executable binary file.