On 04-Jun-2011 06:13 , Joe Pluta wrote:
<<SNIP>> I ran a few tests, and the data read rights allow access via
logical view, while the lack of operational rights DISALLOWS the
creation of additional views or logicals (unless you are QSYS or have
*ALLOBJ).
Which makes it all the more annoying that it's IBM requesting access
to this file. They ought to know better.
Of course "IBM" is rather nebulous with regard to the definitional
and functional aspects of one specific component of the IBM i OS. ;-)
<ed: add>
On 03-Jun-2011 12:57 , Joe Pluta wrote:
It's IBM that requires direct access to the underlying file. First
they wanted *ALLOBJ, and when we balked at that, they refined their
request. I should be more specific: it's the WebSphere folks that
want this information; they evidently haven't gotten the memo on
the "new" access restrictions.
If they believe they need direct access to the physical, then they
would need to ship a program that adopts the authority of a user such as
QSYS or QSECOFR, just like any other OS component or utility\feature
would need to do. Since as I had alluded there is no data that is
available in a QADB* PF which is not also available in a QADB* LF, then
almost surely anyone [IBM or otherwise] could effect pretty much
whatever is required without any special authorities required. While
shipping a logical file in the product is also an option, the database
discourages that since any logical may be deleted without any warning,
and only diagnosed by CPF32D1 to QSYSOPR [thus available in QHST], which
means the feature would need to be restored again for recovery, or have
a program that adopts to be able to recover... and if they can ship such
a program, then they have no limitation to overcome, for which they have
any legitimate case for /needing/ authority to any QSYS/QADB* physical file.
I would guess the more likely their "reason" has origins in
misunderstanding rather than there being any actual requirement. For
example I have seen similar implications made when defects were wrongly
inferred to be functionally correct scenarios, for the query of a VIEW
over the system database cross-reference physical file which resulted in
the message SQL0551 [sqlcode -551]. The misunderstanding was for
assuming the error was correctly being issued, when in fact the query
should have been able to complete without error. Noting however that
such queries should have been coded with the clauses FOR READ ONLY and
WITH NC which preclude references to the member.data which might
otherwise correctly effect that authority failure; i.e. update is
disallowed [not only for authority, but for the ALWUPD attribute of the
file.mbr], and isolation may require access to the physical member in
order to allow access to the journal.
Regardless, the database component "owns" and maintains those files,
and established the authority requirements to those objects, so no other
component of the system should ask of the customer to override those
rules... esp. since as I had noted, the authority to those objects could
be reset by the QDBSRVXR [or other] system jobs at any moment if they
were ever modified.
Any references to the physical files must either be run with or
adopt the authority from a user with the SPCAUT(*ALLOBJ).
Because you can't submit a job as QSYS, and I would guess that you
can't get a profile handle to QSYS either.
I do not believe so, but the *USRPRF QSECOFR always includes the
*ALLOBJ special authority. A handle can be obtained for that user
[instead]. As well, though often not done, any other user could be
setup to have that special authority as well. Plus the requirement for
*ALLOBJ is limited only to the CRTLF or CREATE VIEW, or to the program
that performs the OPEN of the physical file instead of a logical view of
the data. For the create requests, they need only be sure to specify
*OBJOPR object authority and *READ data right to whomever must later
access that new logical view without the [adopted] special authority of
the user that performed the create.
So why anybody who [WebSphere] thinks they require access would not
simply create a program adopting QSYS or QSECOFR, is unfathomable.
Somewhat less so, why anyone might think they need the access in the
first place given the abundance of logical files that provide most if
not all of the physical data, made available generally to the *PUBLIC.
Regards, Chuck
midrange.com
