How to prevent VI from getting a shell?

Eamonn McManus em at dce.ie
Wed Sep 19 20:24:07 AEST 1990


In article <26243:Sep1811:57:4690 at kramden.acf.nyu.edu> brnstnd at kramden.acf.nyu.edu (Dan Bernstein) writes:
>In article <1990Sep17.210110.26060 at robobar.co.uk> ronald at robobar.co.uk (Ronald S H Khoo) writes:
>> I got around the problem by binary patching out the call to fork() in
>> vi.  Ugh.  Also, I never found a way to defeat letting the user read and
>> write files other than the current file.  Any offers ?
>
>A slightly brutish but correct solution is illustrated in the pty
>package. You simply convert exclamation points, colons, and other
>dangerous characters into something dull like a question mark.

This doesn't stop the user from typing Q to get into ex mode, then giving
the command `shell', unless you want to make `Q' a dangerous character.
Mapping Q to <ESC>aQ is too nasty because then you can't insert a Q at
the beginning of a line.

I think the approach of patching the binary is probably the best, in the
absence of a vi clone.  I took the vi on this system (SCO Unix, ugh) and
replaced all occurrences of the strings "sh" and "shell" with null strings
(by overwriting the first byte with 0).  You can do `SHELL=nothing vi'
and there's no way to reset the shell variable.  Now *that's* brutish. :-)

You might want to knock out the :preserve and :recover commands the same
way, for fear that the warped user could pervert them to evil ends.  And
why not nuke :read, :write, :wq, :edit, and :next while you're at it.
Am I paranoid yet?
-- 
Eamonn McManus    <em at dce.ie>    <em%dce.ie at cunyvm.cuny.edu>
	    Fingers are for fuguing.



More information about the Comp.unix.questions mailing list