Troubleshooting
Problem
This document lists some things to keep in mind when setting *PUBLIC (or specific user) authority to the root of the Integrated File System (/).
Symptom
Restricted *PUBLIC authority to the Root (/) in the Integrated File System can cause authority issues/errors. Changes should be made with caution.
Resolving The Problem
Here are some things to keep in mind when setting *PUBLIC (or specific user) authority to the root of the Integrated File System (/).
The shipped value for *PUBLIC authority to the root is *RWX.
1) Root directory is shipped owned by QSYS, there is no authorization list and no primary group. *PUBLIC has all data authorities and all object authorities. QSYS has all data authorities and all object authorities
2) If *PUBLIC only has *RX data authority and *OBJREF object authority, the general public will not be able to create objects in the root and won't be able to see the authority values of the root. It's doubtful they could change any other attributes of the root. They would still be able to read the entries in the root and navigate to subdirectories.
3) Root authority settings impact all physical file systems, but only when using integrated file system interfaces. Users could still access QDLS objects through the old DLO commands (DLTDLO, RNMDLO, DSPDLONAM, DSPDLOAUT, etc.) and they could still access anything in QSYS.LIB through the object-appropriate commands (DLTPGM, CRTSRCPF, RSTLIB, DSPOBJD, etc.)
Users must have at least *RX for basic users to be able to use root, and the *W will give them the ability to create new directories in root.
Users must have *R in order to set or access their own home directory (which can be set on the user profile). Some functions and programs (including some in QSH, when using java, etc) must have access to their home directory.
Users can change *PUBLIC access to root if they wish, but should always remember that they did make this change, and if they start seeing any strange authority errors either set it back to *RWX or give the specific user *RWX authority on the root and test to see if that resolves the issues. If it does, then a decision must be made about how to give the user authority to required resources. This might be done by changing *PUBLIC authority at the root, by granting specific user authority at the root, or by adding the specific user to an Authorization list.
The shipped value for *PUBLIC authority to the root is *RWX.
1) Root directory is shipped owned by QSYS, there is no authorization list and no primary group. *PUBLIC has all data authorities and all object authorities. QSYS has all data authorities and all object authorities
2) If *PUBLIC only has *RX data authority and *OBJREF object authority, the general public will not be able to create objects in the root and won't be able to see the authority values of the root. It's doubtful they could change any other attributes of the root. They would still be able to read the entries in the root and navigate to subdirectories.
3) Root authority settings impact all physical file systems, but only when using integrated file system interfaces. Users could still access QDLS objects through the old DLO commands (DLTDLO, RNMDLO, DSPDLONAM, DSPDLOAUT, etc.) and they could still access anything in QSYS.LIB through the object-appropriate commands (DLTPGM, CRTSRCPF, RSTLIB, DSPOBJD, etc.)
Users must have at least *RX for basic users to be able to use root, and the *W will give them the ability to create new directories in root.
Users must have *R in order to set or access their own home directory (which can be set on the user profile). Some functions and programs (including some in QSH, when using java, etc) must have access to their home directory.
Users can change *PUBLIC access to root if they wish, but should always remember that they did make this change, and if they start seeing any strange authority errors either set it back to *RWX or give the specific user *RWX authority on the root and test to see if that resolves the issues. If it does, then a decision must be made about how to give the user authority to required resources. This might be done by changing *PUBLIC authority at the root, by granting specific user authority at the root, or by adding the specific user to an Authorization list.
Related Information
[{"Product":{"code":"SWG60","label":"IBM i"},"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\/TPS"},"Component":"Integrated File System","Platform":[{"code":"PF012","label":"IBM i"}],"Version":"Version Independent","Edition":"","Line of Business":{"code":"LOB57","label":"Power"}}]
Was this topic helpful?
Document Information
Modified date:
28 January 2020
UID
nas8N1021448