jsev99 succinctly described the *GROUP already, but perhaps the
following, more verbose explanation including a script of actions and
expected results, may prove further enlightening for some. Additionally
I try to address the additional question.
The special value *GROUP is a non-functional symbolic user name. No
authority can be granted to the special value *GROUP, as can be done for
the special value *PUBLIC. The special value *PUBLIC is not only
symbolic to represent all users, but it is _functional_ for both
granting and revoking of authority values. The special value *GROUP is
used only for presentation, to show the requester of display object
authority for an object, that the requester has obtained the listed
authority to that object from a [supplemental] group profile. Thus the
authority was granted to a user profile name that is the same name as a
group profile of the user displaying the authority. I find a scripted
example is often more helpful than /words/ to describe:
crtusrprf zgrp password(*none) usrcls(*user)
crtusrprf zmbr password(*none) usrcls(*user) grpprf(zgrp)
crtdtaara qgpl/dltme *lgl aut(*exclude)
grtobjaut qgpl/dltme *dtaara zgrp *use
sbmjob cmd(dspobjaut qgpl/dltme *dtaara) user(zmbr) job(zmbr)
/* above submitted job runs as user ZMBR, member of group ZGRP */
wrkjob *n/zmbr/zmbr option(*splf) /* 5=Display on QPOBJAUT */
--> Output from the above request by the member of the group:
User Group Obj Aut
*GROUP ZGRP *USE
When a user that does not have ZGRP as a group profile, displays the
authority, the *GROUP does not appear. Instead, the group profile name
is shown as the user that has the authority. That makes sense, since
that is the user to which the above scenario granted the authority. So
if the user performing the above scripted work continues with the
following request:
dspobjaut qgpl/dltme *dtaara
-->output from the display object authority request:
User Group Obj Aut
ZGRP *USE
So in that last display authority request, the user ZGRP does not get
any authority from its group. In fact, the user ZGRP can not have a
group, because it is a group profile.
As can be inferred from the above results, the user ZMBR will have
*USE authority to the object even though *PUBLIC is *EXCLUDE. Thus if
the user has some level of authority via its group, and if that amount
of authority exceeds the expectations for that user, then either
- the group authority must be reduced; take care -- review
applicability for that action for all members of the group. Review the
DSPUSRPRF ZGRP *GRPMBR to see what other members are in the group
- the user must be explicitly granted lower access rights to the
object; most likely scenario?, where that user has a special preclusion
on that object. Review DSPUSRPRF ZGRP *OBJAUT for other objects.
- that user must be removed from the group; Ouch! review how the user
got into the group -- how process & system management failed to effect that
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
Post by r***@deloitte.comI am having some difficulty finding any information regarding the
*GROUP authority assigned to AS400 libraries. Does this designation
act similar to the *PUBLIC authority where it is a catch-all for user
who do not have specific authority assigned?
Ultimately I am trying to determine if this provides any type of
security exposure.