When defining a ZFS file system using the new IDCAMS parameter ZFS, the file system gets formatted at mount time. When this occurs, the owning ID for the directory is assigned UID=0,GID=1, instead of the uid of the issuer of the mount command. For example:
Create a new directory under /z/user1 called zfs
It gets created, and is owned by user1
$ mkdir zfs
$ ls -al
total 40
drwxr-xr-x 3 user1 OMVSGRP 8192 Dec 31 09:03 .
dr-xr-xr-x 119 STCSYS TTY 0 Dec 31 08:16 ..
-rw------- 1 user1 OMVSGRP 350 Dec 31 09:03 .sh_history
drwxr-xr-x 2 user1 OMVSGRP 0 Dec 31 09:03 zfs
$
Then mount a ZFS file system that was created by user1 (uid=0010000999) using the IDCAMS parameter ZFS.
mount -f user1.TEST.ZFS zfs
This changes the owner id of the directory to STCSYS which is UID=0.
$ mount -f user1.TEST.ZFS zfs
$ ls -al
total 40
drwxr-xr-x 3 user1 OMVSGRP 8192 Dec 31 09:03 .
dr-xr-xr-x 119 STCSYS TTY 0 Dec 31 08:16 ..
-rw------- 1 user1 OMVSGRP 421 Dec 31 09:07 .sh_history
drwxr-xr-x 2 STCSYS OMVSGRP 0 Dec 31 09:07 zfs
$ id
uid=10000999(user1) gid=132(SYSPDGRP)
$
There is a permit to the all record for
UNIXPRIV= SUPERUSER.FILESYS.MOUNT OWNER(SYSPDEPT)
ACCESS = UPDATE
Release : 16.0
Component : Top Secret for z/OS
Per IBM:
What is happening here is actually due to being in a USS file sharing sysplex (BPXPRMxx is SYSPLEX=YES). Even though you are issuing the MOUNT from your own NON UID 0 userid that has been given authority to MOUNT via the access to UNIXPRIV SUPERUSER.FILESYS.MOUNT, the mount is actually running on a USS tcb when zFS processes it. This results in the osi_getcred returning UID 0, which is then used, correctly, as the owner.
In a stand alone system environment (NOT a USS File sharing sysplex, or SYSPLEX=NO), the behavior is different. In that case the mount request runs on a tcb associated with the USERs asid (NOT USS, as in the above SYSPLEX=YES environment). This then correctly results in the osi_getcred returning the UID of the user that issue the mount, which is then (also) correctly used as the owner.