We're now going to look at some additional considerations for z/OS UNIX. There are several ways to provide print services to an application and z/OS UNIX application can use the POSIX functions of printf, fprint, write or fwrite to place output in the hierarchical file system. The file can either be specified as standard out or by a filename depending on the function code used. The output residing in the file system can be printed by a batch job using DD statements referring to the outfile by TSO/E print options, or by using the lp shell command. This command dynamically allocates a z/OS SYSOUT dataset, opens, writes, and closes it, and sends it to the jazz pool, which sends it to a printer. Each z/OS UNIX user has a number of default printers specified in different ways. The system will select a printer in the following order. First of all, the printer in the DEST option of the lp shell command or the printf or fprintf functions. The printer specified in the LPDEST environment variable is next. Then three, the printer specified in the PRINTER environment variable. Finally there's four which is the printer in the RACF user profile. Currently HFS files are protected with POSIX permission bits. Permission bits allow the installation to specify read authority, write authority or search authority for a directory. They also allow specification of read, write, or execute authority for a file. Because there are three sets of bits, separate authorities can be specified for the owner of the file or the directory, the owning group and everyone else, such as RACFs Universal Access Authority or UACC. The owner is represented by a UID. The owning group, is represented by a GID. Access checking compares the user's UID and GID to the one stored in the FSP. When a security decision is needed, the file system close RACF and supplies the FSP. RACF makes the decision, does any necessary auditing, and returns control back to the file system. RACF does not provide commands to maintain the FSP, but it does provide soft services that do the FSP maintenance. z/OS UNIX provides commands that invoke these app services. Access control lists or ACLs can be used to control access to files and directories by individual user, by UID, and by group, the GID. ACLs are used along with permission bits. ACLs are created, modified, and deleted using the setfacl shell command. The HFS and ZFS file systems support ACLs. The ACLs are created and checked by RACF not by the kind of file system. There are two kinds of ACL entries. Base ACL entries are the same as permission bits so I will not group another, they can be changed using CH mode or setfacl. Extended ACL entries are ACL entries for individual users or groups. Like the permission bits, they're stored with the file not in RACF profiles. Each ACL type, access file default and directory default can contain up to 1,024 extended ACL entries. Each extended ACL entry specifies a qualifier to indicate whether the entry pertains to a user or a group, the actual UID or GID itself, and the permission's being granted or denied by this entry. The allowable permissions are read, write, and execute. The commands setfacl and getfacl have been introduced in order to create, modify, and display ACL entries specified by the path, and here's the syntax for those. IRRSKA00 is the file checking algorithm. This kind of service has been updated for ACLs and the u UNIX proof profiles. Permissions bits, ACLs, and various UNIX proof profiles are used by RACF while performing file access checks. The RACF basic file checking algorithm checks the owner bits, user ACL entries, union of group bits, and group ACL entries and other bits. Now it's not always necessary to apply ACLs on every file or directory within a sub-tree. If you have a requirement to grant access to an entire sub-tree, for example like sub-tree specific to a given application, access can be established at the top directory. If a given user or a group does not have search access to the top directory, no files within the sub-tree will be accessible regardless of the permission bits set or ACL contents associated with those files. The user or the group still needs permission to the files within the directory sub-tree where appropriate. If this is already granted by the group or other bits, no ACLs are necessary below the top directory. In the next video, we'll look at some remaining and z/OS UNIX considerations.
