On 03/10/2014 08:06 AM, Elardus Engelbrecht wrote:
> Florian Luetscher wrote:
>
>> I would like to give a group of users access to browse and only browse a 
>> VSAM dataset using DITTO. 
> As Binyamin Dissen said, just give Read access. 
>
>> The DITTO/ESA Inst. and Cust. Guide references a RACF profile 
>> DITTO.VSAM.UPDATE. But that's exactly what I dont want to give them. Maybe 
>> access to PROGRAM(DITTO) is enough.
> You can use PROGRAM(DITTO) which is useful for limiting usage of DITTO itself 
> for example, but not for above scenario for VSAM datasets.
>
>> Any idea how to proper set up RACF in this case? 
> Try giving access to DITTO.VSAM.UPDATE in FACILITY Class to certain 
> persons/groups and create DITTO.** and give it UACC = Read. (See Binyamin's 
> note above.)
>
> Or just use this for example:
>
> DITTO.FUNCTION.VB  <-- Browsing VSAM datasets. Give UACC=READ.
> DITTO.FUNCTION.VE  <-- Editing VSAM datasets. Give specific access as needed.
> DITTO.**                  <-- To close all remaining DITTO holes.
>
> Remember to protect your VSAM datasets properly too. This is more important. 
> Protect the resources, not the tools only.
>
> That should get you a go.
>
> Groete / Greetings
> Elardus Engelbrecht
>
>
>
It seems rather odd to want to only allow READ access through a specific
program, unless that program is also able to restrict what you can see
-- and I wasn't aware that was a characteristic of DITTO.  But if you
really want to implement this, no one seems to have mentioned RACF
program-controlled access.  RACF PROGRAM profiles can be used both to
control access to specific programs and to conditionally control access
to data sets.

You first have to have an explicit PROGRAM profile for the program in
question (DITTO).  PROGRAM profiles must also be associated with one or
more datasets from which the program might be loaded.  You also must
have a program-controlled environment, which means that all programs
loaded into the environment must be under the control of some PROGRAM
profile.  This generally means you need a generic "**" PROGRAM profile
associated with all libraries in the LinkList and any other libraries
you might need to reference in a program-controlled  job step so you
won't unintentionally lose your program-controlled environment when some
unknown (to the typical user) module is loaded internally by the main
program -- and the difficult-to-remember part is that if the names of
libraries in the LINKLIST change, this profile must be updated
accordingly.  To be on the safe side, be sure to create these PROGRAM
profiles with UACC READ before activating PROGRAM profiles so as to not
shoot yourself in the foot by immediately denying access to all programs
for all users!  Once those are in place, do not grant the restricted
class of users any direct access to the DATASET profile covering the
VSAM cluster in question, but do grant the restricted class of users
program-controlled READ access to that profile (see the WHEN(PROGRAM(...
)) option of PERMIT).  That way they only have READ access to the
dataset when the main program is DITTO.  Also note that PROGRAM profiles
are cached in memory and require an explicit REFRESH to pick up any changes.

Even if RACF PROGRAM profiles are not used to deny program access to any
users, the PROGRAM profiles must exist and be active in order to have a
"program-controlled" environment and in order to have program-controlled
access to DATASET profiles.

As already implied, the effort to implement this technique doesn't
really make sense from a security standpoint unless the program through
which restricted access (READ or UPDATE) is given is able to limit what
the user can do to only a subset of what direct READ or UPDATE access to
the data set might allow.

-- 
Joel C. Ewing,    Bentonville, AR       [email protected] 

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

Reply via email to