Editor With NO Shell Access?

Robert Bonomi bonomi at mail.r-bonomi.com
Mon Mar 12 20:47:33 UTC 2012

> From owner-freebsd-questions at freebsd.org  Mon Mar 12 14:22:29 2012
> Date: Mon, 12 Mar 2012 14:19:06 -0500
> From: Tim Daneliuk <tundra at tundraware.com>
> To: FreeBSD Mailing List <freebsd-questions at freebsd.org>
> Subject: Editor With NO Shell Access?
> I have a situation where I need to provide people with the ability to edit
> files.  However, under no circumstances do I want them to be able to exit
> to the shell.   The client in question has strong (and unyielding) InfoSec
> requirements in this regard.
> So ... are there editors without this feature?  Can I compile something like
> joe or vi to inhibit this feature?

If the need is for 'simple'/'minimal' editing -- as opposed to, say, regex-
based global-search-and-replace, A more-or-less 'easy' way to do this could 
be to use a web browser.

.htaccess to determine who can access what file, probably from a specific

a cgi-bin that, on validate access,  loads the file into a 'textarea' 
on a <form>.  (form has a 'hidden' field that identifies the file being 

User makes changes in the 'text' block, clicks 'update' (form 'submit'
button) when finished.  There's a .htaccess on the form-processing cgi-bin
to re-validate the submission. (prevents somebody 'faking' a file update
without actual permission.)  The cgi-bin then re-writes the edited file.

Depending on 'security' requirements, you may need a shared-memory
cache -- used between the two cgi-bin invocations -- to provide 'session'
locking, prevent 'overlapping' updates, and trap _all_ 'forged' file

This has some 'maintainablity' advantages over the 'hacked' editor 
approach. It's much clearer to a future person just _what_ is going on.
It's also clear to the user what they can, and _cannot_ do.  This has
major beneficial effect on those who attempt to 'push the limits'. 
Hack the editor to disable functionality, and _somebody_ *will* complain
that they =need= that functionality, for a 'superficially plausable'

Otherwise, hacking the source code for, say, 'vi', should -not- be very
difficult.  Look for the logic that processes '!!' or ":!" at the beginning
of an input sequence, and disable the related functionality.

You could probably make a dinky little library  -- with 'fake' routines
for 'fork', 'exec', and 'pipe'; routes that 'do nothing' other than raise
a security alert, and include that in the compile/link for a customized 
'vi', before 'libc'.

More information about the freebsd-questions mailing list