dorl@vms.macc.wisc.edu (Michael Dorl) (04/28/88)
I'd like to talk to anyone who has written their own command language interpreter for VMS. Better yet, I'd like to see an example. What I need to do is to provide a highly efficient platform to restrict certain users to a subset of available programs and commands so I need a CLI that accepts and parses user commands, loads the required programs, and provides whatever interfaces the VMS CLI would otherwise provide. Michael Dorl (608) 262-0466 dorl@vms.macc.wisc.edu dorl@wiscmacc.bitnet
leres@ucbarpa.Berkeley.EDU (Craig Leres) (04/29/88)
Michael Dorl (dorl@vms.macc.wisc.edu) writes: > I'd like to talk to anyone who has written their own command language > interpreter for VMS. Better yet, I'd like to see an example. What > I need to do is to provide a highly efficient platform to restrict > certain users to a subset of available programs and commands so I > need a CLI that accepts and parses user commands, loads the required > programs, and provides whatever interfaces the VMS CLI would otherwise > provide. Why not just use DCL? Armed with the verb program that has been posted several times and the command definition utility that comes with VMS, it should be very easy to write a .cld file that does exactly what you want and is "safe." Craig
narayan@tandem.UUCP (Narayan Mohanram) (04/30/88)
In article <23809@ucbvax.BERKELEY.EDU> leres@ucbarpa.Berkeley.EDU (Craig Leres) writes: >Why not just use DCL? Armed with the verb program that has been posted >several times and the command definition utility that comes with VMS, >it should be very easy to write a .cld file that does exactly what you >want and is "safe." > > Craig Writing your own CLI gives you the advantage of running some code in the Supervisor mode, and being able to do Callbacks to it. DCL may not provide all you are looking for. This way you can have any type of call-back you desire, not those limited by DCL (I admit I do not know much about the command defenition utility). Narayan Mohanram THE SUPREME DALEK
jmb@beach.cis.ufl.edu (John M Boof) (05/05/88)
In article <191@dogie.edu> dorl@vms.macc.wisc.edu (Michael Dorl) writes: >I'd like to talk to anyone who has written their own command language >interpreter for VMS. Better yet, I'd like to see an example. What >I need to do is to provide a highly efficient platform to restrict >certain users to a subset of available programs and commands so I >need a CLI that accepts and parses user commands, loads the required >programs, and provides whatever interfaces the VMS CLI would otherwise >provide. > Since I am not sure where you are heading, this may not be applicable to your situation, but if it is, you had better realize this: If you end up using the Command Language Definition utilities to create your own command tables with certain commands filtered out, you will not keep the user of this command table (tie them to the table in the uaf file) from using those 'hidden' commands. They cannot execute the images themselves eaffectively, since any required qualifiers would cause the image to crash. They can, however execute images that only need parameters by setting up a symbol to run the image (doit := $sys$system:type) beforehand. And even if this is acceptable, the user can simply re-install the commands that you took away from them with a SET COMMAND command, using the DCLTABLES file, or using their own CLD file (which has VERB extractions of the missing ones). And if you search the commands that they enter to filter out some verbs, that won't stop them either, since they can use symbols equated to the command, or can make new command verb names in a CLD file that uses the same image as the normal command would. Now if you were REALLY going all out to write you own executeable image that parses and passes control to your own selected images, this may not apply. However, have you considered the SPAWN/CLI=DCL command as a way to get around this altogether? The only real way to protect certain commands from being executed by certain users is to set ACL's on the images themselves. You may want to keep a list of restriced users, and write a com-file that automatically modifies all of these acl lists on all of these images whenever you want to add or delete someone from this list of restricted users. ...JMBoof hotline%decnet.oak@pine.circa.ufl.edu or hotline%dnet.oak@vlsi2.ee.ufl.edu or boof@pine.circa.ufl.edu or jmb@beach.cis.ufl.edu (some of these may work - some may get confused ) BITNET: boof@ufpine
JOE@FHCRCVAX.BITNET (Joe Meadows) (07/01/88)
Craig Leres <leres@ucbarpa.Berkeley.EDU> writes: >Michael Dorl (dorl@vms.macc.wisc.edu) writes: >> I'd like to talk to anyone who has written their own command language >> interpreter for VMS. Better yet, I'd like to see an example. What >> I need to do is to provide a highly efficient platform to restrict >> certain users to a subset of available programs and commands so I >> need a CLI that accepts and parses user commands, loads the required >> programs, and provides whatever interfaces the VMS CLI would otherwise >> provide. >Why not just use DCL? Armed with the verb program that has been posted >several times and the command definition utility that comes with VMS, >it should be very easy to write a .cld file that does exactly what you >want and is "safe." I can think of some reasons not to use DCL. You can't restrict the user all that much. Sure, you can remove many commands, but the foreign command interface isn't removable, so many things can't be restricted. If you leave in the SET COMMAND command they can rebuild their tables. The only way to completely restrict an account is to have a captive account and some kind of a shell procedure, but then you don't really need to modify DCLTABLES at all. Not to discourage you from using verb or anything (I did write it for a reason)... I'd like to see an example command language interpreter. It would be quite interesting to try alternate interfaces. Surely anyone who has had to work much with the command definition utility wishes that it were more capable. Doesn't everyone have a few pet peeves with DCL? Imagine being able to rewrite SPAWN, and getting rid of the need to send all symbols, key definitions, and logical names through a mailbox to the newly created process, spawns could be as fast as sys$creprc.. Imagine multiple subprocesses sharing exactly the same CLI (i.e. one copy in memory, shared key definitions, shared symbols, etc...). Tell ya' what, if people send me their pet peeves (with DCL/VMS), I'll collect a list and summarize it to the net.. Well, enough of this random rambling, I'll let y'all get back to work now... Cheers, Joe Meadows Jr. VAX/VMS System Manager / guru in training Fred Hutchinson Cancer Research Center 1124 Columbia St. Seattle Wa. 98104 bitnet - JOE@FHCRCVAX arpa - JOE%FHCRCVAX.BITNET@OLY.ACS.WASHINGTON.EDU voice - (206) 467-4970