disallowing subshell in More

[Guy Harris]

> >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