*GROUP AUTHORITY - IBM AS400

This is a discussion on *GROUP AUTHORITY - IBM AS400 ; I 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? Utimately ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: *GROUP AUTHORITY

  1. *GROUP AUTHORITY

    I 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?

    Utimately I am trying to determine if this provides any type of
    security exposure.


  2. Re: *GROUP AUTHORITY

    On Aug 29, 4:25 pm, rbar...@deloitte.com wrote:
    > I 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?


    you probably mean group profiles. where group profiles are profiles
    like any other, except other user profiles specify the group user
    profile name on their GRPPRF parm of the CRTUSRPRF command.

    when you DSPOBJAUT or EDTOBJAUT libname *lib you see all the profiles
    that have authority to the library. If a group profile is one of the
    profiles displayed, all the members of the group have authority to the
    library.


    >
    > Utimately I am trying to determine if this provides any type of
    > security exposure.


    a lot of shops *EXCLUDE *PUBLIC from the library and then grant group
    profiles *use rights to the library. Within the library *public could
    have rights to its objects, but since they cant access the library,
    *public cant access the objects.

    the security exposure to look for are profiles with *allobj authority
    and programs which adopt the authority of the program owner.

    -Steve




  3. Re: *GROUP AUTHORITY

    On Aug 30, 8:25 am, rbar...@deloitte.com wrote:
    > I 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?
    >
    > Utimately I am trying to determine if this provides any type of
    > security exposure.


    *GROUP
    *GROUP is simply saying that is a group profile.
    is what has been granted authority.


  4. Re: *GROUP AUTHORITY

    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

    rbarnes@deloitte.com wrote:
    > I 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.


+ Reply to Thread