Correct. Somebody has 'broken' the production system by having done
CHGOBJOWN QUSRSYS/QAUGDBLL *FILE TECH_SUPPORT CUROWNAUT(*REVOKE). The
QAUTPROF user profile is a system profile that maintains authority for
the availability of users to access features of OpsNav; a form of
application authority. When that user does not have the authority to a
functional object, the users without *ALLOBJ special authority will not
be able to access the function represented or performed by that object.
The user profile is shipped as *USER [what I call *PEON] and provides
adopted authority [primarily to QUSRSYS *LIB] to be able to access some
functions & objects without adopting a user profile with *ALLOBJ; that
would be excessive. On most systems DSPUSRPRF QAUTPROF *OBJAUT will
show only *CHANGE to QUSRSYS *LIB, and aut to itself. And DSPUSRPRF
QAUTPROF *OBJOWN will show several programs QZDGD* in QIWS and several
database files QAUGD* in QUSRSYS. FWiW: It is possible the change was
in response to output from DSPPGMADP QAUTPROF, without regard to
consequences -- but again, that is a *PEON user, so when it is adopting,
it should gain nothing except to what it owns or to what it is
explicitly authorized.
The object QAUGDBLL is the current implementation object [as an
implementation detail, is subject to change] for the Database component
of OpsNav, for the library list feature.
Although I do not agree with the design approach taken by the GUI dev
[by coding only from the client to create and store the data in a DBF on
the server versus having underlying i5/OS install support to create the
files during install vs run-time // or if it is even necessary or any
value-add to store on the server vs the client for this particular
function], the authority will be necessary to use the function. And the
change made to the file owner, with the revoking of the current
authority, will have caused the same problem even if the files had been
installed versus created by the GUI component.
The authority to the file must come from either the user of the
function, or the adopting user QAUTPROF. So with regard to the
situation probably requiring "an act of Congress to get our sysadmins to
do anything about this," you will probably want to start your petition
for change to congress. ;-)
Given exclusionary authority established on the server, then I am not
aware of any integrity concern for allowing the user to set their own
library list. And if the user changing their library list is supported
generally, I would expect that would be desirable for Database OpsNav
users as well. So if the situation is explained, that the i5/OS GUI is
broken [for the database feature] due to the revoked authority to that
file for the user QAUTPROF, hopefully the sysadmins will understand and
correct that error without too much of a fight.?
Irrespective of any possible consequences for having changed the
authority, I see relatively little possible chance for a negative
outcome due to the ownership change. Noting however, that as a
customization, it would need to be performed as part of system
maintenance as part of system change management to maintain consistency
if that is really desirable. Nothing prevents the system from reverting
the file owner and authority during an install (of maintenance even) or
upgrade.
Regards, Chuck
-- All comments provided "as is" with no warranties of any kind
whatsoever and may not represent positions, strategies, nor views of my
employer
Dan wrote:
<SNIP>>
The production box, otoh, shows that it was intentionally modified:
Object . . . . . . . : QAUGDBLL Owner . . . . . . . : TECH_SUPPT
Library . . . . . : QUSRSYS Primary group . . . : *NONE
Object type . . . . : *FILE ASP device . . . . . : *SYSBAS
Object
User Group Authority
*PUBLIC *USE
Chuck, since you are familiar with this file and process, are you aware of
any reasons why this particular file should be locked down? I mean, it's a
glorified library list!!!!!!! Is there a security vulnerability?
- Dan
midrange.com
