When enabling the JVM component of Sysview on systems running Websphere a security error message is displayed:
ICH408I USER(SYSVUSR ) GROUP(CASTG) NAME(SYSVIEW STC) 263
/var/pgwt/websphere/config/AppServer/java64/bin/java
CL(DIRSRCH ) FID(D6F0D7F1F5C604900000000000060005)
INSUFFICIENT AUTHORITY TO STAT
ACCESS INTENT(--X) ACCESS ALLOWED(OTHER ---)
EFFECTIVE UID(0120001114) EFFECTIVE GID(1100001094)
ICH408I USER(SYSVUSR ) GROUP(CASTG) NAME(SYSVIEW STC) 264
/var/pgwt/websphere/config/AppServer/java64/bin/java
CL(DIRSRCH ) FID(D6F0D7F1F5C604900000000000060005)
INSUFFICIENT AUTHORITY TO LSTAT
ACCESS INTENT(--X) ACCESS ALLOWED(OTHER ---)
EFFECTIVE UID(0120001114) EFFECTIVE GID(1100001094)
Release : 16.0
Component : SYSVIEW
The Sysview JVM component will automatically discover JVM address spaces running on the system. When a JVM address space is found, it will run some commands against the java executable that the JVM address space is using. For example, it will run the USS command "java --version" to get the version of the JVM being used.
In the error message provided, it is the user id SYSVUSR (this is the SYSVIEW STC user id), was trying to do something that required execute permissions on the file: /var/pgwt/websphere/config/AppServer/java64/bin/java
The SYSVIEW user id would require execute permissions when trying to execute the "/var/pgwt/websphere/config/AppServer/java64/bin/java --version" command like discussed above.
Commonly, JVM address spaces will share a single java executable file. However, in the case of Websphere address spaces, it appears that Websphere provides it's own java executable file. No matter where the java executable file lives, the SYSVIEW user id will need execute permissions to that file in order to gather data about the JVM. However, if the SYSVIEW user id does not have execute permissions to that file, there should be no other impact besides not seeing some information about the JVM on JVMLIST, like the JVM version. The JVM itself and the JVM component in SYSVIEW should still function normally.
In conclusion, the SYSVIEW user id needs for java executable files.
Some additional information on this matter:
The error message occurs because the SYSVIEW user id (SYSVUSR) did not have execute permissions to the file: "/var/pgwt/websphere/config/AppServer/java64/bin/java".
SYSVIEW wants access to a Websphere file because SYSVIEW will execute the java executable used by a JVM address space. In the case of Websphere, Websphere provides their own copy of the java executable file.
To prevent these problems from reoccurring, it's needed to grant the correct permissions to the SYSVIEW user id. It's possible to model the permissions after the java executable file(s) that is being shared amongst your other JVM address spaces. To find the java executable file a given JVM is using, use the JVMLIST command within SYSVIEW. Then use the "Version" line command on a given JVM. This provides the JVMVERS display which has ResolvedHome and Home fields. Underneath the directory indicated by these fields exists a /bin directory. In this /bin directory exists a file named "java". This is the java executable file used by the JVM seen on JVMLIST. If there isnt an error message in other JVM address spaces, that means the SYSVIEW user id had correct permissions to the java executable file. It is then possible to model the permissions for the Websphere java executable file after the shared java executable file.
Not hitting this problem on the development/test systems is either because there were no Websphere address spaces running or the SYSVIEW user id had correct permissions to the Websphere java executable file.