The daily edition.

Scope: Rocket Enterprise Developer / Enterprise Server 12.0 for Eclipse (UNIX documentation); Remote File Access (RFA) listeners in an enterprise server region or standalone MFCS server.

What an RFA listener exposes

An RFA listener provides remote access to files on the host system, so the manual stresses that it must be properly secured. Access is controlled by several layered mechanisms. The Remote File Access conversation type covers remote access to normal filesystem files, local and remote access to the Enterprise Server JCL spool and cataloged datasets, and local and remote access to the COBOL File Service used by the IDE-integrated COBOL data file editor. See Remote File Access conversation type.

Layer 1: allowed paths are required

At least one allowed path must be configured for an RFA listener to serve files. By default no paths are defined as allowed or denied, and undefined paths are implicitly denied, so by default no access is given to any file. Allowed and denied paths are entered in the configuration text area of each RFA listener, under the [Allowed paths] and [Denied paths] sections. Each entry is a file-system path, optionally including wildcards. See RFA security.

An allowed path can optionally be mapped to a different file-system path. With the documented allowed-path entry /a/directory=/a/different/directory, a request to download /a/directory/file.txt accesses /a/different/directory/file.txt.

The [Denied paths] section is described as primarily useful for removing access to specific subdirectories beneath an area listed in [Allowed paths]. See Remote File Access conversation type.

Layer 2: user authentication and PHYSFILE rules (ESF)

A client must begin with a logon request before requesting any file operation. When the region or standalone MFCS server that owns the listener has security enabled, ESF authenticates the username and password in that request.

With security enabled, RFA also makes an ESF authorization request for the file-system path under the PHYSFILE resource class, so matching PHYSFILE resource rules must exist for the paths RFA is meant to reach. The manual notes that allowed paths are checked first, before PHYSFILE rules. See RFA security.

For RFA, PHYSFILE behaves differently than it does for JES:

• Wildcard interpretation
  • *: matches zero or more of any characters except the / path separator.
  • **: matches zero or more characters, including the slash.
• Access permissions
  • The permissions currently supported are none, read, update, and all, interpreted as separate permissions rather than a single access level.
  • A rule can list several permissions separated by commas, for example read, update.
  • Read permission is required to download a file, and update permission is required to upload a new or altered file.
• Path canonicalization
  • On Windows, backslash characters are converted to forward slashes in both rule names and candidate paths.

Layer 3: narrowing the listener itself

Two optional [Security] settings limit what the listener will do regardless of file-system permissions and PHYSFILE rules.

The access option sets the maximum access level (read, update or alter). The documented example prevents RFA from modifying, creating, or deleting any files:

[Security]
access=read

The allow feature option restricts which RFA features are enabled. The documented example disables all catalog operations and access to cataloged datasets:

[Security]
allow catalog access=no

The manual adds that the physical file holding the dataset data might still be directly accessible if a suitable allowed path is configured. Rocket Software suggests that customers using RFA consider the access and allow feature options to disable RFA features they do not need. See Remote File Access conversation type.

Operating system permissions and TLS

Operating system file permissions apply to all operations performed by the listener, which runs under the user account used to start the region or standalone server. For a region started by ESCWA, this is the enterprise server user account on UNIX. The manual states that Rocket Software does not recommend relying on operating system permissions to restrict RFA access, though they can serve as an additional defense. Like other enterprise server listeners, RFA supports TLS (SSL), and Rocket Software recommends configuring it for RFA listeners to help ensure data confidentiality and integrity. See RFA security.

Operational nuance: configuration changes

The RFA connector checks its configuration options when started and when modified, and changes affect current and new conversations. See Remote File Access conversation type.

The conversation type also provides diagnostic options. The [Filter Options] entries parser trace=yes|no (trace allow and deny rule parsing) and debug rules=yes|no (trace the application of allow and deny rules) are described as being for convenience or diagnostics.

Takeaway

In Enterprise Developer 12.0 for Eclipse (UNIX), an RFA listener serves nothing until [Allowed paths] is populated; allowed paths are evaluated before ESF PHYSFILE rules, and the [Security] options access and allow feature can further limit what the listener will do.