disallowing subshell in More

[David Canzi]

>> >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. ...
>> 
>> 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.
>
>System V has an editor called red(1) which is just a restricted version of
>ed(1).  The restrictions are that you can only edit files in the current
>directory and the '!' shell escape command is disallowed.

The solution to the *real* problem, that of preventing the user from getting
unrestricted use of too much privilege has already been posted -- fork, then
setuid to the user's own userid, then exec to more.  This way the user can
do what he bloody well pleases, safely.

I worked as a systems programmer on CMS, for the very same organization for
which I am still working, and was much disenchanted with a local abomination
called "student CMS".  Student CMS is a "padded cell environment", in which
the user is deprived of most of the facilities available to regular CMS
users.  Internally, almost every useful facility implemented in CMS has to
have ugly kluges inserted to check whether it is being used from student
CMS and not to work, or to work differently if so.  A great deal of effort
has gone into implementing student CMS, and much effort must be spent on
maintaining it.  Bluntly, much potentially productive effort has been used,
instead, to reduce the capabilities of the system.  I consider this a
perversion of the natural order of things.

The facilities provided by the Unix kernel for keeping Joe Random User out
of places where he doesn't belong are sufficient.  Use *them*, instead of
building padded cells, okay?  I do not approve of red(1), now that I know
it exists.
-- 
	David Canzi