1. 25 Apr, 2003 2 commits
  2. 13 Mar, 2003 1 commit
    • Chad Barb's avatar
      · c6129ad7
      Chad Barb authored
      More rework on the groups system.
      
      * BESTOWGROUPROOT permission added to dbdefs.
      
      * Permissions criteria for group operations changed in dbdefs
        (consult code for full explanation.)
      
      * Approveuser and Editgroup now check for BESTOWGROUPROOT
        permissions before allowing changes to group_root.
      
      * approveuser_form and editgroup_form do not show "Group Root"
        as an option unless you are allowed to set it (or it is already set.)
      
      * editgroup does not UPDATE rows where trust has not been changed.
      
      * showgroup does a correct check to see whether to show the
        "group options" subpage.
      c6129ad7
  3. 12 Mar, 2003 2 commits
    • Chad Barb's avatar
      · 24940013
      Chad Barb authored
      * Altered consistency checks to treat any root as equivalent
        (so, if you're project_root in the default group, but group_root in
         a group, that won't be a problem)
      
      * Moved consistency checks, which were done in two different places into
        dbdefs TBCheckGroupTrustConsistency()
      
      * Added preemptive checks, so if 'user' or '*_root' are not valid
        trusts, they aren't displayed as options in editgroup_form and
        approveuser_form (using above function)
      
      * In approveuser, a new approval may now be sent to group_root.
      24940013
    • Chad Barb's avatar
      · bb14f708
      Chad Barb authored
      Split notion of "EDITGROUP" permission into two:
      "EDITGROUP" and "GROUPGRABUSERS".
      
      "EDITGROUP" is easier to obtain;
                  it is now given to group_root for the group.
      "GROUPGRABUSERS" is how "EDITGROUP" _used_ to be:
                       only given to default-group_root or project_root.
      
      The ability to add users to a group who have not requested membership
      now requires "GROUPGRABUSERS".
      
      Removing or editing members still requires only EDITGROUP.
      
      So, the upshot is, now group_root users can edit and remove members from
      their own groups.
      But they still can't 'grab' users who haven't asked to join the group.
      (which would enable them to mount arbitrary users' home dirs as
       root, which would be a Bad Thing.)
      bb14f708
  4. 27 Feb, 2003 1 commit
    • Leigh B. Stoller's avatar
      * No longer put the project leader into every subgroup. If the project · 08770694
      Leigh B. Stoller authored
        leader wants to be in the subgroup, he has to do it via the editgroup
        page. This required minor changes in editgroup pages, since I was special
        casing the project leader to not allow removal/addition.
      
      * Allow mere users to be the head of a group. This was previously not
        allowed, and is totally wrong since the entire group trust mechanism
        is based on giving subgroup members *more* privs then they have in
        the default (project) group.
      
      * Change permission check in the showgroup page to allow non group members
        to look at the group if they have group_root or better in the default
        group. I noticed that once I took myself out of a group, I could no longer
        look at the group even though I had group_root in the project.
      
        Also change so that the edit/del menu does not appear unless the user
        has permission to do those things.
      
      * Change consistency check when adding a group member. New test is simpler
        and makes sure that the user does not have root privs in the project and
        user privs in the subgroup. The reverse is of course okay, and the expected
        manner in which groups should be used.
      
      * newgroup page now spits out a redirect to showgroup page, rather then
        printing the group info itself. Avoids duplication and gets rid of the
        form post from the history. Ditto for editgroup page.
      08770694
  5. 24 Jan, 2003 1 commit
    • Leigh B. Stoller's avatar
      Major reorg of deleteuser page. Dump the old rmacct-ctrl (finally!) · 250f9c20
      Leigh B. Stoller authored
      and replace with script to delete a user, either from a single project
      or from the entire testbed. All of the DB stuff is done in the script;
      the web interface no longer does anything but error checks. This is
      because removing a user requires some finess in when things are
      removed, and if there are any failures I wanted to make sure that the
      script could be rerun on a user, without barfing.
      
      Add lots of error checks to make sure not deleting a user who is
      "important" (project head, group head, experiment head, etc).
      
      Add "request" mode. If a project leader deletes a user from his
      project, and the user has no more project memberships, show a click
      button to send us email requesting the user be deleted from the
      testbed.
      
      Bottom line, project leaders can now delete users from their project,
      but must ask us to delete the account from the testbed.
      250f9c20
  6. 20 Jan, 2003 1 commit
  7. 01 Nov, 2002 1 commit
  8. 07 Jul, 2002 1 commit
  9. 26 Dec, 2001 1 commit
    • Leigh B. Stoller's avatar
      A bunch o' account managment script schanges. I have reworked · 46068860
      Leigh B. Stoller authored
      mkprojdir, mkacct-cntrl, mkgroup, and group-update into a set of new
      scripts that are more specific to their intended operation, and strive
      to do less work.
      
      1. mkacct - Replaces mkacct-cntrl. This script no longer does any
         group stuff. All it does is create new accounts, or update the
         password and gecos fields of existing accounts. Usage is the same
         as it was: "mkacct <userid>", and is typically invoked from the web
         interface via the approveuser form.
      
      2. mkgroup - Replaces group-update. This script creates new groups,
         either for the main project when it is approved, or for subgroup
         creation. This script does not alter the group membership. Usage
         is typically from the web interface, but mkgroup can be invoked
         from the command line: "mkgroup [-b | -a] <pid> <gid>" where -b
         puts it in the background and sends email later, while -a just
         captures the log and emails. This "audit" feature is going to find
         its way into more scripts as soon as I figure out a neat and clean
         perl mechanism to make it easy.
      
      3. setgroups - Replaces group-update. This script modifies the group
         membership of either specific users, or all the users in a
         project. It is typically invoked from the web interface when a
         project leader edits the subgroup membership or when a user is
         first approved to a project or subgroup. Command line usage is:
      
      	setgroups [-b | -a] -p <pid> [user ...]
              setgroups [-b | -a] [user ...]\n
      
         The first form is mostly a means to speed things up. The web
         interfaces knows exactly what users have need to be changed, but a
         global project update is nice too.
      
      4. mkproj - Replaces mkprojdir. Actually, mkproj still has all that
         directory code, but it also handles creating the groups and the
         account for the project leader. Part of my policy to move as much
         random code out of the web interface and into the PERL backend
         where it belongs.
      46068860
  10. 20 Dec, 2001 2 commits
    • Leigh B. Stoller's avatar
    • Leigh B. Stoller's avatar
      And finally, all those groups changes I've been whining and yammering · c13d27c3
      Leigh B. Stoller authored
      and complaining about this week.
      
      1. editgroup: You can now edit the trust levels for existing group
         members (default group too), and you can specify trust levels when
         adding users to subgroups.
      
      2. approveusers: When approving users in the approval page, you can
         specify different levels of trust. Before, I invisibly set all the
         trust values the same. I also added some ordering to the DB query
         to group users together.
      
      3. I added a great deal of error checking to the processing pages for
         both forms. I split things up into a pre/post pass. The prepass
         goes through all of the form args and checks them for consistency
         and correctness. Nothing is changed in the DB unless all checks
         pass for all args. Then I do a second pass and make the changes.
         Both scripts set the ignore_user_abort() flag to prevent the user
         from stopping the script and causing a DB inconsistency.
      
      4. Added trust consistency checks as well. Rather than allow the
         project or group leader to set inconsistent trust levels, I look
         for those and just plain disallow them. You may not give different
         trust levels in different subgroups of the *same* project, and you
         may not give a user a higher trust level in the default group than
         in the subgroups. Both edit and approve make these checks, and the
         code is absolutely awful.
      c13d27c3
  11. 17 Oct, 2001 1 commit
  12. 16 Oct, 2001 1 commit