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
midrange.com
