How To
Summary
Site requires machine to have no public directories. However, on the Information Server service tier machine, the permission of directory
/tmp/javasharedresources changes to public (777) each time WebSphere restarts. How can I prevent this permission change?
Steps
The directory /tmp/javasharedresources is managed by the java virtual machine (JVM). It is the JVM, not WebSphere, that is changing the directory permission when WebSphere launches its JVM and loads shared classes.
A java property exists which allows you to define an alternate directory for java shared classes and also what permission should be used for that directory. Using alternate directory in this case is needed since there are limits on changes we can make to the usage of special directory /tmp/javasharedresources.
Use the following steps to remove public permissions on directories for java shared classes:
A java property exists which allows you to define an alternate directory for java shared classes and also what permission should be used for that directory. Using alternate directory in this case is needed since there are limits on changes we can make to the usage of special directory /tmp/javasharedresources.
Use the following steps to remove public permissions on directories for java shared classes:
- Remove public permission from /tmp/javasharedresources: chmod 770 /tmp/javasharedresources
- Create new directory to be used for WebSphere classes, using userid that WebSphere runs with (usually root), for example:
mkdir /data/javasharedresources
chmod 770 /data/javasharedresources - Login to the WebSphere Administrator Console and add the following java properties to be used in WebSphere startup.
Note that the 2 options (cachDir and cashDirPerm) MUST appear in the listed order and MUST use the exact case shown:
-Xshareclasses:cacheDir=/data/javasharedresources,cacheDirPerm=0770
In the example above, we define that the JVM will use alternate directory /data/javasharedresources for shared classes, and when it creates that directory it will give it permission 770, thus there will be no public permission.
When WebSphere then starts it's JVM, the default directory /tmp/javasharedresources will no longer be used thus permission will not get reset to 777. You can confirm after WebSphere startup that a new class is written to the new directory location.
If after this change the permission on directory /tmp/javasharedresources is set back to 777, then you may have other applications on that machine which load their own JVM and load shared classes. You can look at the class name and owner to determine what other applications may be using this directory -- those applications will need similar java property added to prevent permission changes to this default directory.
When WebSphere then starts it's JVM, the default directory /tmp/javasharedresources will no longer be used thus permission will not get reset to 777. You can confirm after WebSphere startup that a new class is written to the new directory location.
If after this change the permission on directory /tmp/javasharedresources is set back to 777, then you may have other applications on that machine which load their own JVM and load shared classes. You can look at the class name and owner to determine what other applications may be using this directory -- those applications will need similar java property added to prevent permission changes to this default directory.
Document Location
Worldwide
[{"Line of Business":{"code":"LOB10","label":"Data and AI"},"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SSZJPZ","label":"IBM InfoSphere Information Server"},"ARM Category":[{"code":"a8m500000008XGPAA2","label":"WebSphere Application Server->WebSphere Configuration"}],"ARM Case Number":"TS003524964","Platform":[{"code":"PF002","label":"AIX"},{"code":"PF016","label":"Linux"}],"Version":"11.5.0;11.7.0;11.7.1"}]
Was this topic helpful?
Document Information
Modified date:
06 November 2020
UID
ibm16361673