Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!cbatt!ihnp4!houxm!ho95e!wcs
From: wcs@ho95e.UUCP
Newsgroups: comp.unix.wizards
Subject: Re: \"special\" shells a security hole?
Message-ID: <1317@ho95e.ATT.COM>
Date: Sat, 7-Feb-87 19:10:20 EST
Article-I.D.: ho95e.1317
Posted: Sat Feb  7 19:10:20 1987
Date-Received: Mon, 9-Feb-87 02:20:54 EST
References: <3953@brl-adm.ARPA> <2590002@hpisod2.HP> <3037@gitpyr.gatech.EDU>
Reply-To: wcs@ho95e.UUCP (46133-#Bill.Stewart,2G202,x0705,)
Organization: AT&T Bell Labs 46133, Holmdel, NJ
Lines: 18

There's been a discussion on providing restricted environments without
using chroot, and how to deal with shell escapes from editors, BBSs, more,...

In article <3037@gitpyr.gatech.EDU> robert@gitpyr.UUCP (Robert Viduya) writes:
>Actually, you can "disable" shell escapes from more(1) or ex(1) or any
>other program that follows conventions by simply setting the SHELL
>environment variable to a null program before executing the program.
>.....
>Watch out for programs that allow shell escapes but ignore SHELL, though.
>I don't know of any that do, but that doesn't mean they don't exist.
>They're anti-social anyway.

The "system(3)" subroutine call does this, at least on V7, 4.1BSD, and
System V Release 0 and 2.  A lot of commands use it, including /bin/mail.
Aside from being anti-social (4.*BSD and SVR2 are old enough to know better),
it can also be a source of bugs and/or security risks.
-- 
# Bill Stewart, AT&T Bell Labs 2G-202, Holmdel NJ 1-201-949-0705 ihnp4!ho95c!wcs