Security messages when enabling JVM
search cancel

Security messages when enabling JVM

book

Article ID: 219923

calendar_today

Updated On:

Products

SYSVIEW Performance Management

Issue/Introduction

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)      

Environment

Release : 16.0

Component : SYSVIEW

Cause

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.

Resolution

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.

Additional Information

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.