USS privileges to delete files with 777 permissions
Article ID: 267144
Updated On:
Products
Issue/Introduction
A user is getting a permission denied error when trying to delete a USS file. The file has 777 permissions set.
Why is the user unable to delete the USS file?
Running the ACF2 ACFRPTOM report shows that the user does not have access to callable service: ck_owner_2_files:
ck_owner_2_files TESTUSR TESTGRP xxxxxxxx 1 8 8 4
05/31/23 23.151 11.28.44
Failed - Caller not authorized to use this callable service
Function: unlink User Type: Local
Pathname: test.filename.xml
Filename: /CWD
File Permissions: Owner: rwx Group: rwx Other: rwt
Owning UID: 0 Owning GID: 20
Volume : xxxxxx File Identifier:
File Audit Options:
User : Read Failure Write Failure Exec/Search Failure
Auditor : Read None Write None Exec/Search None
File Permissions: Owner: rwx Group: rwx Other: --t
Owning UID: 0 Owning GID: 20
Volume : xxxxxx File Identifier:
File Audit Options:
User : Read Failure Write Failure Exec/Search Failure
Auditor : Read None Write None Exec/Search None
Environment
Release : 16.0
Resolution
If HFS SECURITY ACTIVE: NO is seen in the output for a SHOW UNIXOPTS command in ACF2, the system is using native OMVS security to secure HFS/ZFS files.
The OM report shows the sticky bit is set on this file. This is the "t" that is seen in the "File Permissions" section:
File Permissions: Owner: rwx Group: rwx Other: --t
When the sticky bit is set in OMVS, according to IBM OMVS documentation, a user can remove or rename a file or remove a subdirectory only if one of these is true:
-The user owns the file or subdirectory.
-The user owns the directory.
-The user has superuser authority.
If ACF2 security was active for OMVS (HFS SECURITY ACTIVE: YES), the sticky bit is ignored and access is granted based on resource rule access.
Feedback
