Verifying and setting file permissions

Non-root users performing installation and subsequent installation operations (SIOs) on the application server product can verify whether they have the correct permissions to ensure that the installation operation can be completed successfully, without failure due to file permission errors. In addition to the function which verifies file permissions, you can set the ownership and permissions (with limitations) on all installed files.

SIOs include operations such as feature installations, edition upgrades, maintenance installations (such as fix packs or refresh packs), feature pack installations, and slip installations of custom installation packages (CIPs) created with IBM® WebSphere® Installation Factory. You can change file ownership and permissions after installation using the chutils command.

[Windows] Restriction: The verify and set permissions features are not currently available on Windows® operating systems.

Verifying file permissions

When an application server installation is initially performed, the resulting installation is owned by a single user and group. Certain SIOs can be performed by another user whether the user is root or non-root.

Use the verify permissions utility to determine whether a subsequent installation operation would fail due to insufficient file permissions. You can run this check as an optional function in the standard application server installer, CIPs, and the Update Installer. If the check fails, the installation operation is prevented until the error has been resolved. The installation operation is prevented in order to avoid corruption of installations caused by an incomplete subsequent installation operation. Without a successful installation permissions check, an unexpected file permission error could occur. This would cause the installation to fail and leave the product in an indeterminate state.

The verify permissions utility is available in the installation wizard as a check box on the installation summary panel before you begin the actual installation process, or if you are installing silently, then you can run the utility by uncommenting the -OPT checkFilePermissions="true" option in the response file.

During the verify permissions check, the installer does not create or modify any product files. The permissions check only confirms whether the file operations would succeed based on file ownership and permissions. The target location is not modified as a result, and no configuration actions are run.

If the verify permissions check fails, then all file permission problems that occur during the simulation are written to a log in the user's home directory. Entries in the log files will indicate which files are not writable by the current user including file names, file operations, and specific permission issues. You can address file permission errors and rerun the verify permissions utility without exiting the installation wizard. The log file is located in the <user_home>/waslogs/log.txt directory.

Setting file ownership and permissions with the chutils command

You can use the chutils command to set the file ownership and permissions for an entire installation to an owner or group that differs from the user that performed the initial installation. The main benefit is the ability to have the initial install performed by one user and then have different users perform supported SIOs. The chutils command is located in the app_server_root/instutils directory.

The command can be used for the following:
  • Add or remove the ability of other non-root users to update the installation
  • Transfer all file ownership of the installation to another user
  • Reestablish consistent file permissions for the entire installation
The command can edit the following ownership and permissions:
  • File owner
  • File group
  • Owner permissions

    You can only change owner permissions to the default values set during installation through the -setmod=reset parameter.

  • Group permissions

    You can elevate group permissions to match the owner permissions using the -setmod=grp2owner parameter.

  • Others permissions

    You can only change others, or "world" permissions to the default values set during installation through the -setmod parameter.

Table 1. The chutils command.

This table describes chutils command options.

Option Description
-installlocation=<install_home> Optional. The absolute path to the installation root directory. Defaults to the current install location, or app_server_root.
-setowner=<username> Sets the owner for each file and directory.
-setgroup=<groupname> Sets the group for each file and directory.
-setmod=[reset]|[grp2owner]
Sets the permissions on the files and directories.
  • reset - Resets the owner, group and other permissions to the default values.
  • grp2owner - Sets the group's permission to match the owner's permissions.
-help Displays the permission utility's help.
-debug Displays additional runtime information.
Considerations and limitations:
  1. chutils is intended to be run by root.
  2. chutils can be run with multiple options at once.
  3. Cannot modify permissions for parent directories of app_server_root. For example, if app_server_root is in User A's home directory, and the root user uses chutils to change the ownership of app_server_root to User B, then app_server_root might still be inaccessible to User B since it is still a subdirectory of User A's home directory.
  4. Cannot modify permissions for owner or world, although group permissions can be elevated to match owner permissions.

Troubleshooting




Related concepts
Non-root installations
Concept topic    

Terms of Use | Feedback

Last updated: Oct 21, 2010 12:21:13 PM CDT
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=v701sca&product=was-nd-mp&topic=cins_nonroot_permissions
File name: cins_nonroot_permissions.html