× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.