×
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.
The DSPSRVAGT is apparently not part of the OS, and thus it seems
also not documented in the Security Reference:
http://publib.boulder.ibm.com/infocenter/iseries/v6r1m0/topic/rzarl/sc415302.pdf
The documentation for the LPP that provides that command should
suggest *SERVICE authority is required, and should probably note
that additionally either the special authority *ALLOBJ or some other
"specific private and\or special authorities" may be required to use
the individual commands\features [e.g. those that implement menu
options], or even to use a particular [special] value specified for
a command parameter. Although the *SECADM might be required for
some individual requests [e.g. for granting the capability to a user
to view the service agent information], I would guess that the more
typical requirement that is not met would be for lack of the
*IOSYSCFG special authority.
An example of documentation like what I would expect, is from the
following PDF "Chapter 5. Set up and Configure Hardware Problem
Reporting":
http://publib.boulder.ibm.com/isrvagt/pdfs/52ESAUser.pdf
"A user profile (other than QSECOFR) with *SECOFR authority with
*ALLOBJ, *SECADM and *IOSYSCFG special authorities. A user without
*ALLOBJ authority would need to have specific authority to the
objects accessed by Electronic Service Agent. See Appendix A.
Authority Requirements for the specific authorities required."
The "Chapter 7. View Electronic Service Agent System Information"
suggests:
"You can authorize users to access this information by providing
valid IBM Registration user IDs. You must have all object (*ALLOBJ)
authority and security administrator (*SECADM) special authority. To
authorize users to view server information, do this:"
Together, those two documentation references would not make the
requirements entirely obvious to me. That is, it is not obvious to
me, whether like with *ALLOBJ, the *SECADM might be optional; e.g.
when doing something other than when authorizing "users to access
this information". For lack of a section describing exceptions for
*SECADM or *IOSYSCFG, like there is for *ALLOBJ, perhaps they deemed
the former two special authorities are best just always required
rather than trying to document specifically where they would be
required.?
Regards, Chuck
rob@xxxxxxxxx wrote:
Of course, you have to have the authority to
get into that <ed: GO SERVICE, option 6> command, as
coworkers have shown me.
User needs *ALLOBJ and *SECADM. Tried *ALLOBJ and *SERVICE; that
didn't work. Just some silly thought that *SERVICE authority
seemed a natural fit for the SERVICE menu. Apparently IBM is
under the belief that *SECADM is needed to do SERVICE.
Message . . . . : Not authorized to object SERVICE in QSYS.
Cause . . . . . : You do not have the correct authority for
object SERVICE in library QSYS type *MENU.
And once they got past that...
Not authorized to command DSPSRVAGT in library QSYS.
This is what option 6 runs: DSPSRVAGT TYPE(*SRVREGINF)
So you could skip giving them authority to the SERVICE menu and
adopt authority to that command. Hopefully a "DSP" command
doesn't pucker up some security officers frown.
Object . . . . . . . : DSPSRVAGT
Library . . . . . : QSYS
Object type . . . . : *CMD
Object secured by authorization list . . : *NONE
Object
User Group Authority
*PUBLIC *EXCLUDE
QSRVAGT *ALL
QSRV *USE
And after you get through that hurdle...
Not authorized to program QS9DSP1 in QSYS.
Not authorized to service program QS9UTIL in QSYS.
Not authorized to service program QSJSRVAGT in QSYS.
Not authorized to service program QSJUTIL in QSYS.
...
...
...
midrange.com
