Granting a user UID(0) (also known as SUPERUSER) does not allow a user complete access to do anything in USS.
There are Standard Unix checks that will fail UID 0 attempts to execute some files. Both ACF2 and RACF conform to this Unix standard. The following
3 links below that confirm that this is a Unix standard.
a) http://luv.asn.au/overheads/unixperms/index.html
(The Unix Permission System) states:
under '3. Processes':
"There is one special user ID in the system, the superuser ID: 0. It can do (almost) anything to objects in the system."
------
under '4. Permissions'
"To execute a binary program, execute permission is needed. Even the superuser must obey this."
b) http://marc.info/?l=racf-l&m=128268136926112
' Re: RACF stops USS Superuser from executing a file' states:
> > All, Apparently if you are Superuser, RACF won't let you execute a
> > program if none of the permissions for the file allow "execute", that
> > is the owning UID doesn't have execute, nor do the owning
> > gid, nor the world.
response:
> This is standard UNIX usage, so I would expect that it is the exec()
> function which is checking for eXecute being ON and not allowing the
> file to be used as a program (script, whatever) if it is OFF. If z/
> OS UNIX did allow this, I can imagine the "astonishment" factor for
> users from other UNIX environments.
c) http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ICHZA7B0/E.4.4?SHELF=ichzbk
'E.4.4 Authorizing Access to z/OS UNIX Files and Directories'
item 15 states:
"If the user has UID(0), then access is granted automatically unless the user is executing a file. If the user is executing a file, access is
denied only if none of the permissions bits grant execute access, and, if an ACL is present and the FSSEC class is active, no ACL entry grants
execute access. Otherwise, access is granted."