Defining delegated resources
Some applications and daemons initiate requests that require access to resources to which the client who invoked the daemon might not otherwise need access. For example, the FTP daemon (FTPD) shipped with z/OS® Communication Server requires access to sensitive ICSF resources that the FTP client does not. Generally, you must authorize the client user IDs to access resources that are needed by the daemon. However, if instructed by the documentation for the application or daemon, such as the FTP daemon, you can define a particular resource as a delegated resource and authorize it for use by the daemon's user ID rather than by the client user IDs.
Delegated resources are general resources that are eligible to be accessed by specially programmed applications that request RACF® to check the application, or daemon's, authority for a resource when the client's authority is insufficient. Applications programmed in this way, such as the FTP daemon, are said to contain support for nested ACEEs because the identity of the application or daemon is said to be nested beneath the identity of the client for authorization purposes.
You indicate that a resource is a delegated resource by adding
the text string RACF-DELEGATED
to the APPLDATA field
of the profile protecting the resource. The RACF-DELEGATED
text
string will always be translated to upper case by the RALTER or RDEFINE
commands.
The RACF-DELEGATED
text string can appear anywhere
within the APPLDATA field, allowing for the existence of other information
already in the field, or for new information that might be added in
the future.
RDEFINE CSFSERV CSFENC APPLDATA('RACF-DELEGATED')
RALTER CSFSERV CSFENC APPLDATA('RACF-DELEGATED')
RALTER CSFSERV CSFENC APPLDATA('THIS RESOURCE IS A RACF-DELEGATED RESOURCE')