Re: Is there an easy way to find out what LPAR you are in?

[CRPence <CRPbottle@xxxxxxxxx>]

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