Thanks Colleen. Could you please pass this response back to DirMaint Support?
This is our production system, and we certainly want to control who
can issue DirMaint commands. The question is the best way to do
this. In general we want to make things secure, but also easy to use
for the few authorized userids.
Note that we do NOT give DirMaint authority to all of our users. We
give it to a few systems programmers, and a few staff at the Help
Desk that are responsible for creating VM userids.
To do this, we use the following DirMaint configuration files:
AUTHFOR CONTROL
AUTHDASD DATADVH
(Jim was probably thinking of AUTHFOR CONTROL when he said AUTHBY CONTROL.)
We also use RACF to restrict access to 5VMDIR30 11F, the DirMaint
primary interface code disk, to only the userids we intend to have
DirMaint privileges.
With all of that in place to restrict who can issue DirMaint
commands, we don't want to also have to have each privileged user
respond with a password to use DirMaint.
I'll leave it up to Jim to respond to "If he would follow the
documentation given with the product he is informed of everything he
needs to know about." First he needs to take more of his blood
pressure medicine.
Thanks,
Mark Bodenstein ([EMAIL PROTECTED])
Cornell University
At 01:56 PM 11/16/2007, you wrote:
From DirMaint Support:
What they have done is made every command be not prompted for a
password. Which of course is not the way DirMaint typically
runs. Someone, probably on the listserv, told them in the past they
could alter the cmds file to remove them from password
authorization. Something which I would typically describe as
dangerous but perhaps on their education/test system it is what they want.
With this in mind these files are not typical files to be needing
tailoring at all. The are tailorable if there is some special case
which they seem to have.
This is why they are not discussed in the documentation (TAG).
In the case of AUTHBY CONTROL this is built when you use the AUTHBY
function for BYUSERS. There are several control files in DirMaint
which get built because the external command was issued. Therefore
there is no need for the customer to be informed of this file.
If he would follow the documentation given with the product he is
informed of everything he needs to know about.
By default DirMaint requires passwords. The way they operate as
discussed they are not. However, if the issue a NEEDPASS command
which is an optional command it could confuse the issue.
What I believe they should have done to give everyone access to all
commands by making every command a GENERAL use command. Then the
password prompt would not be so confusing. But as long as they know
what they have done there is no issue. Just be aware that this
could be dangerous.
They are giving access to everyone to DASD commands which could be a
loaded gun in the hands of the wrong people
Colleen M Brown
IBM z/VM and Related Products Development and Service
Jim Bohnsack <[EMAIL PROTECTED]>
Sent by: The IBM z/VM Operating System <IBMVM@LISTSERV.UARK.EDU>
11/14/2007 01:10 PM
Please respond to
The IBM z/VM Operating System <IBMVM@LISTSERV.UARK.EDU>
To
IBMVM@LISTSERV.UARK.EDU
cc
Subject
Re: dirm needpass no
I took a look at doc for 140CMDS and 150CMDS and now I see the Y or N
called out for col 35. I overlooked that as I did the last time we
upgraded DIRMAINT. Mark found it then as he did now. What I don't
understand is what appears to be the fact that there are so many places
in DIRMAINT, both the client side and the server side where
authorization is granted. On the client side, there appear to be
GLOBALV options that can be set and there is also the DIRM NEEDPASS NO
or YES. On DIRMAINT, there is the Y or N in the 1x0CMDS DATADVH file
but there is also the AUTHBY CONTROL file. The descriptions for all of
them seem to be scattered in different manuals rather than having a
section in the Tailoring and Admin. manual. That makes setup of
DIRMAINT really messy as does many of the different configuration files.
Jim
