Re: Access rights to system files

On 03-Jun-2011 10:57 , Joe Pluta wrote:

Working with IBM on a related issue, I determined that the *PUBLIC
access for QADBXREF (and probably a bunch of other files) is set to
an unusual configuration: the only access granted is Data Read
authority. A standard *USE setting has both Data Read and Execute
rights as well as Object Operational rights. Testing indicates that
the latter (Operational) rights are required in order to execute SQL
against the file.

My question is two-fold:

1. Is this the same setting others see on their systems? *PUBLIC
having ONLY data read rights, with no object rights whatsover?

The correct *PUBLIC authority for each of the [non-RDB] physical files maintained by the system database cross reference is the one data authority [AKA data right] of *READ, with no private authorities except for the owner which [for a successful install] must be QSYS. Any other setting is an unsupported authority configuration. While the authority to those files is not easily modified since they are effectively always open, the authority of those database *FILE objects may be [re]set to the expected value at any moment while the any of the QDBSRVXR, QDBSRVXR2, or SCPF jobs are active.

2. What does this setting mean? I can't even do a DSPPFM on the file.
So why give the data read rights as all? This isn't the only file
like this - other physical files in QSYS have similar settings.
(Although interestingly enough logicals over those same physicals
are accessible.)

Lacking any object rights, users lacking the special authority *ALLOBJ can not access any data directly from the physical file [so DSPPFM is not an option for such users], nor create any VIEW or any INDEX over one of those PF QADB* in QSYS. With that implementation [effectively enabling row and column security], only the specific data that should be visible to the general *PUBLIC is manifest via a logical view of the specific columns and rows. However AFaIK there are still no columns in any of those PF which are not exposed via one of the logical files; I believe each physical still has at least one logical which shares the record format of the physical. If ever there were to be some data protected in that manner, not exposed via a logical, the underlying authorities of the existing physical files would not have to be changed. In other words, the implementation reflects a design which intended to avoid an incompatible change in the future.

Any references to the physical files must either be run with or adopt the authority from a user with the SPCAUT(*ALLOBJ).

Note: There have been occasional incidents of defects whereby a reference to a VIEW built over a cross-reference physical, a VIEW to which the user has the required *OBJOPR object right and *READ data right, incorrectly receives a -551 [SQL0551] condition for a PREPARE, OPEN, or FETCH. The problem would not be specific to the database cross-reference, but to the authority setup whereby the underlying physical file(s) do not have the *OBJOPR. The query engine or other processing must set pointer authority to include the *OBJOPR, and that system pointer must be utilized instead of referencing a pointer obtained while adopted authority is not active. The symptom for such problems may also include a logged MCH1001 for a *MEM, *QDDS, or *FILE object.

And as a side comment, has it always been the case that you can't
grant someone *USE access to a menu if someone else is using it? That
seems a little bit finicky, especially for the MAIN menu.

Most complex object types for which the "use" of that object includes maintaining a lock, will prevent changing the object authority until a moment when there are no "uses" currently active. That is because the object handler must get an *EXCL lock on all of the composite pieces that make up the external object type and assign the new authority to all of those object; i.e. to operate with atomicity. That said, I do not know enough about the object type *MENU [i.e. if even that is a complex object type which has an object handler] to comment more specifically.

Regards, Chuck