mab@ntcsd1.UUCP (Mark Bradford) (11/22/89)
We have an application that allows the users to us vi. What we would like to do is to keep the users from accessing the shell. We currently do not allow the users to use ":!command" by setting the SHELL environment to a script. The problem has arisen that some of our users have learned to use the set shell option in vi. Is there any way of disabling this option? Thanks in advance.
prs@tcsc3b2.tcsc.com (Paul Stath) (11/25/89)
mab@ntcsd1.UUCP (Mark Bradford) writes: >We have an application that allows the users to us vi. What we would >like to do is to keep the users from accessing the shell. We currently >do not allow the users to use ":!command" by setting the SHELL environment >to a script. The problem has arisen that some of our users have learned >to use the set shell option in vi. Is there any way of disabling this >option? Why would you want to cripple vi like this? IMHO, this is one of the nicest features of vi which I use daily. I have the function keys set to do usefull things like reformat a paragraph, get the current tima and date, etc. But rather than debate the merits of vi shell command escapes, I'll assume you have a valid reason, soooo, here are a couple of methods you can try. 1) Look at what type of vi you are running. Some vi's have a security option. (I think BSD does?? It's been sooo long since I've used BSD) If the option is not set on the command line it may be invoked when started by an rsh. (Similar to the red version of ed) System V R3.2 doesn't seem to support it. 2) You might be able to set up a vi macro that blows away the ability to set the shell. I will dig out my vi references and see if I can figure this one out, and post the solution. Of course, this requires that the .exrc file cannot be changed by the user. Of course, if you have the source to vi, or some other popular editor, you could hack out the shell escape functions altogether, call it, oh say, r<editor> and call that from your application. Of course, the BEST solution would be to make it so that no more processes could be forked from the editor process, and call whatever editor the user is most comfortable using. (Pick this up from the EDITOR environment variable) Any system programming gurus out there know how to make a child process that can't fork??? I'm claiming ignorance in this area. I'll look around and see what I can find out on this end. But at least you get the idea of a direction to head in. Good luck, I'd like to hear what your solution turns out to be. -- =============================================================================== Paul R. Stath The Computer Solution Co., Inc. Voice: 804-794-3491 ------------------------------------------------+------------------------------ INTERNET: prs@tcsc3b2.tcsc.com | "There was no diety involved,
lee@sq.sq.com (Liam R. E. Quin) (12/01/89)
>mab@ntcsd1.UUCP (Mark Bradford) writes: > >We have an application that allows the users to us vi. What we would >like to do is to keep the users from accessing the shell. We currently >do not allow the users to use ":!command" by setting the SHELL environment >to a script. The problem has arisen that some of our users have learned >to use the set shell option in vi. Is there any way of disabling this >option? Yes, you can use "adb" on vi to change /bin/sh into /bin/xx, and have a program called "xx" in /bin which does what you want. Do this to a *copy* of vi... You will almost certainly lose the ability to do :r a* but this is a relatively small price to pay. You can also do map ! x map! ^V^V x map! ! x to prevent people from typing "!". But this is not good, as it disables a lot of useful things, like !!spell -b % If you want a slightly more secure environment, you could consider using chroot (with a little care...). If you want to restrict users who've exceeded their disk quota, you could use the ed clone from comp.sources.misc (today) and disable the ! command. Lee -- Liam R. Quin, Unixsys (UK) Ltd [note: not an employee of "sq" - a visitor!] lee@sq.com (Whilst visiting Canada from England, until Christmas) utai!anduk.uucp!lee (after Christmas) ...striving to promote the interproduction of epimorphistic conformability