Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site rlgvax.UUCP
Path: utzoo!watmath!clyde!bonnie!akgua!sdcsvax!dcdwest!ittvax!decvax!linus!philabs!cmcl2!seismo!rlgvax!guy
From: guy@rlgvax.UUCP (Guy Harris)
Newsgroups: net.unix-wizards
Subject: Re: disallowing subshell in More
Message-ID: <484@rlgvax.UUCP>
Date: Thu, 14-Feb-85 02:21:27 EST
Article-I.D.: rlgvax.484
Posted: Thu Feb 14 02:21:27 1985
Date-Received: Sun, 17-Feb-85 05:34:23 EST
References: <8279@Berkeley.UUCP> <9500003@philabs.UUCP>
Organization: CCI Office Systems Group, Reston, VA
Lines: 37

> >It's beginning to look like the law of diminishing returns is taking
> >effect - you might want to write a simple pager that doesn't do anything
> >other than page files.
> 
> Okay, Guy, great.  But what if you want your users to use a program like 
> vi?  Then what?  I would like users to be able to use an editor.  Vi and 
> most other editors, with the exception of some of the third-party
> (expensive) stuff, allow the user to escape to a shell.

To quote from the original article:

> Does anyone know of a way to pipe a file to more and disallow a user from
> invoking a subshell while More is running?
> 
> Here's the senario, I have a menu that allows certain users to have root
> access to several functions (unjamming the print queue, archiving &
> restoring files, etc).  One of the options is to allow the user to get a
> listing of a tape archive to the screen (piped through More) which of course
> allows the user to type a '!sh<return>' and viola! a root shell.

Either the operator won't want to use "vi" to look at the listing, in
which case this isn't a problem, or they do, in which case they can't do
it without buying or writing an editor (or browser) which forbids spawning
shells.  Life's tough.  I wasn't advocating throwing "more" out; I was
advocating replacing the pager in this particular example with something
simpler.  Perhaps a simple browser (a read-only screen "editor", in effect;
"editor" is really a misnomer) would be what's called for.

The point of my comment is that one problem with feature-rich tools is that
nobody may understand them fully, and may get bitten by a hidden side-effect
(like being able to do the "more"->"vi"->shell sequence).  It was beginning
to look like "more" had features that, in the given application, were
security holes (and weren't easily pluggable).  A simpler tool (like "p"
or a browser) would probably be less likely to have those holes.

	Guy Harris
	{seismo,ihnp4,allegra}!rlgvax!guy