FSUMF353 __chattr() could not set audit_flag_type audit flags for filename When Converting From HFS To ZFS

Products

• Cleanup
• Datacom
• DATACOM - AD
• CIS
• COMMON SERVICES FOR Z/OS
• 90S SERVICES
• DATABASE MANAGEMENT SOLUTIONS FOR DB2 FOR Z/OS
• COMMON PRODUCT SERVICES COMPONENT
• Common Services
• CA ECOMETER SERVER COMPONENT FOC
• Easytrieve Report Generator for Common Services
• INFOCAI MAINTENANCE
• IPC
• UNICENTER JCLCHECK COMMON COMPONENT
• Mainframe VM Product Manager
• CHORUS SOFTWARE MANAGER
• CA ON DEMAND PORTAL
• CA Service Desk Manager - Unified Self Service
• PAM CLIENT FOR LINUX ON MAINFRAME
• MAINFRAME CONNECTOR FOR LINUX ON MAINFRAME
• GRAPHICAL MANAGEMENT INTERFACE
• WEB ADMINISTRATOR FOR TOP SECRET
• Xpertware
• Top Secret
• Top Secret - LDAP
• Top Secret - VSE

Issue/Introduction

Description:

When converting from HFS to ZFS (using HFSSEC security in CA Top Secret), the IBM REXX exec to copy HFS file to ZFS file results in the following error:
FSUMF353 __chattr() could not set audit_flag_type audit flags for filename

Solution:

Here are some things to check regarding this error:

1. Have an SCA acid that is a superuser issue the Unix "find" command to list all files that have auditor audit options set to "fff":

     find / -aaudit =f                                                        

   Issue the Unix "df" command to display mounted filesystems.
   
   Check every mounted filesystem in the "df" output to see if it also shows up in the "find" command output. If so, the auditor audit options for that filesystem should be changed from "fff" to "---" (no auditing).
   
   Issue the Unix chaudit command to change the auditor audit options from "fff" to "---". This example changes the auditor audit options for the /SERVICE filesystem:

     chaudit -a -f /SERVICE                                                   

   Issue similar chaudit commands for every filesystem that has incorrectly set auditor audit options.
   
   
2. Be sure the directories are mounted as read/write and NOT as READ only.
   
   
3. Check to see if there are old HFS files that have the auditor flags enabled? This error could occur for older HFS files which have the auditor flags enabled. If this is the case, copy the files from one HFS to another newer HFS and then convert to a ZFS.
   
   
4. 1. If the files are shared by two lpars, if one lpar owned the mount, the audit file can not be changed from the other lpar.
   2. If some directories were mounted as read only, the mount had to be changed to read/write in order to remove the flag.

If none of the above correct the problem, a security trace with the AUDIT attribute also on the acid, OMVS trace, and TSSOERPT will be needed to pursue.

Here are the instructions to activate the traces.

1. TSS ADD(acid) TRACE AUDIT
2. TSS REFRESH(acid) JOBNAME(*)
3. TSS MODI(SECTRACE(ACT,WTL))
4. ST SET,TYPE=OMVS,FUNC=ALL,END (issued on the console)
5. This will route all trace records to the MVS syslog....
6. Recreate the problem.
7. TSS MODI(SECTRACE(OFF))
8. ST DEL,ID=xx (issued on the console)
9. TSS REM(acid) TRACE
10. TSS LIST(acid) DATA(ALL,PROFILE)
11. Please email trace to [email protected] with the issue number as the subject.

For the TSSOERPT, there is sample jcl in member TSSOERPT in the TSS SAMPJCL library. See also chapter 9 of the TSS 12.0 Report and Tracking Guide for more info on TSSOERPT.

Environment

Release:
Component: AWAGNT