CAS2312E TSOABCD - READ ACCESS DENIED
Article ID: 12070
Updated On:
Products
Issue/Introduction
A user with access to "/u.%" is receiving the following error when he attempts to get to his home directory:
CAS2312E TSOABCD - READ ACCESS DENIED
/U
***
The TSSUTIL report shows the following...
10/20/16 08:27:27 TSOABCD TSOABCD READ READ OK+A HFS ? ROOT
10/20/16 08:27:27 TSOABCD TSOABCD READ NONE *08*-88 HFS ? /U
10/20/16 08:27:35 TSOABCD TSOABCD READ READ OK+A HFS ? ROOT
10/20/16 08:27:35 TSOABCD TSOABCD READ NONE *08*-88 HFS ? /U
***
After the CAS message he presses the <enter> key and can then access his directory.
Why?
Environment
Component:
Resolution
What you describe is somewhat normal.
The /u directory is typically just a tree node to contain all the individual user directories. The requirement to create files in /u/uuuuuuuuu is typically only to have access to the file. For example, when creating a directory /u/binky from ISHell, we saw the following security trace entries:
TSS-F-0000*TCSFJA TCSFJA T HFSSEC 200A G/0005000300,FF20000000 L/300002 F/04000320,
TSS-1 1C000000FFFF 00000000 T/0000000400 /u.binky
TSS-2 6D0000 R/128200 S/500100,08802C000800 A01TE028 A/990080 P/EXEC ,3502,
TSS-4 00000000 006FC680 7F5FC8D0 REQ/SAFHFSEC SUB/CA-HFS
The problem is that it depends upon the way in which the files are created. We don't know the specifics of how the application is creating this file. From the traces, we can see three separate opendir calls issued for: /, /u, and /u/tsoabcd. Each of those calls is converted to an HFSSEC resource check as it is received.
When performing tests on our test systems using ISHell, we do not see any opendir calls at all. We see the following calls:
For Creating a directory:
CARR852D MKDR Calling IBM USS function
For Creating a file in /u/binky
CARR850D OPEN /u/binky/apples
For accessing (edit) the file
CARR850D ACCS /u/binky/apples
Once we went back and read the /u/binky directory to get a directory list we got the opendir check as follows:
CARR850D OPDR /u/binky
The opendir check only occurred for the single directory being requested. There is not a check for each node along the path. The fact that you are seeing multiple checks for each node tells us some part of the process is asking for the directory access.
CA Top Secret accommodations to HFSSEC security are that we will simply externalize any security check security issued by USS. The requirements for accessing HFS directories and folders should not be any different between native USS and HFSSEC. The only difference should be where the security information is pulled from.
We have performed a similar check from a windows FTP client. To access any directory only requires access to that directory, not any of the other directories in the path.
Feedback
