I have taken the stance that the fewer UDCs, the better. I use UDCs for
LOGON to set the environment, e.g., HPPATH and to prevent most users from
accessing the system prompt. A second valid purpose for UDCs is to replace
system commands, i.e., restrict users from access or specify parameters.
Some third party applications provide UDC files and some with commands are
longer than 8 characters, e.g., COGNOS, so it is just easier to use their
UDCs than try create command files for each command. However, all the 200+
UDC commands I found on the system when I assumed management, e.g., SJ, AJ,
L, SS, etc., etc., I converted to command files. The command files are
kept in a group with global "execute only" access and the group is added to
HPPATH during logon.
Managing an HP-3000 and protecting its environment can be very difficult
unless you can really take complete control. There are many steps needed
to accomplish this. One of them is to restrict certain system commands.
This is an example of a UDC I use to restrict SETCATALOG, NEWGROUP, ALTGROUP
and PURGEGROUP by online users. The users see what a appears to be an MPE
error message. I also log execution attempts with Security/3000. The
implications of SETCATALOG have been enumerated in this thread. The reason
I restrict the NEW/ALT/PURGEGROUP commands is to manage disk space with
multiple volume sets. Note that there are no restrictions in these
commands if executed in a Job. So job submission should be managed as
well.
SETCATALOG
ANYPARM U=![""]
OPTION NOLIST,NOHELP
IF HPJOBTYPE = "S" THEN
XEQ MAIN.PUB.VESOFT "CALC SECURITYLOG('SETCATALOG !U')",1
IF POS("SM",HPUSERCAPF) = 0 OR HPACCOUNT <> "SYS"
ECHO
ECHO EXECUTING THIS COMMAND REQUIRES SYSTEM MANAGER CAPABILITY. (CIERR
725)
RETURN
ENDIF
ENDIF
CONTINUE
SETCATALOG !U
*******
NEWGROUP
ANYPARM U=![""]
OPTION NOLIST,NOHELP
IF HPJOBTYPE = "S" THEN
XEQ MAIN.PUB.VESOFT "CALC SECURITYLOG('NEWGROUP !U')",1
IF HPACCOUNT <> "SYS" THEN
ECHO
ECHO EXECUTING THIS COMMAND REQUIRES SYSTEM MANAGER CAPABILITY. (CIERR
725)
RETURN
ENDIF
ENDIF
CONTINUE
NEWGROUP !U
*******
Good luck!
Tom Genute
-----Original Message-----
From: Donna Garverick [mailto:[log in to unmask]]
Sent: Friday, June 15, 2001 3:37 PM
To: [log in to unmask]
Subject: Re: UDC vs Command files
[log in to unmask] wrote:
> I am surprised that no one mentioned the risk of relying on one's HPPATH
(or
> any path on any system) to resolve a command file name. Some
mischief-maker
> can place an identically named command file in your path, before the
> location of the desired command file, with unpleasant results.
greg's right. i would dearly love to see an enhancement (maybe tied into
the
system-level ci variables project??) that allows...i don't know...i'll call
it
'rules' that can be attached to critical variables like hppath. i had a
royal
battle with some less-than-informed users who were insisting on completely
resetting hppath in their own (account) logon udc. they were repeatedly
calling
saying 'this' is broke or 'that' is broke and it was because they were using
a
'nonstandard' hppath. at least for me, if i could 'configure' hppath to be
'append only' by ordinary (not 'sm') users that would be helpful. i'd
certainly
still want the system to set up hppath according to how it's set in the
system
logon udc...but after that? append only.
> Also, I'm likewise surprised that no one mentioned the option of having a
> UDC invoke a command file, possibly even of the same name as the UDC
itself,
> for those of us who are simple-minded in their naming conventions (I'm
well
> known around here for that sort of thing).
and this is exactly how i'm 'testing' replacement operator udcs on my
production
system. - d
--
Donna Garverick Sr. System Programmer
925-210-6631 [log in to unmask]
>>>MY opinions, not Longs Drug Stores'<<<
* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
|
