User Managed Groups

Some groups, although ongoing, have frequent changes to their membership; for example students joining and leaving a project every semester. In order to save the project leaders the trouble of emailing SystemSupport every time they want a change in group membership of a group, such groups may be setup as a User-Managed Group, commonly known as a UMG.

These behave similarly to normal Unix groups and still have to be created by SS but once created they can be controlled by the group owner. Operations available to the group owner include adding and removing members, extending the UMG's expiry date and destroying the UMG. Only the group owner can add members to the UMG but members may remove themselves. Anybody can list the members of a UMG. All these operations are performed by the priv umg command. Emails are automatically sent to the group owner and members upon UMG creation and membership changes. The default expiry date on a UMG is one year, which can be extended up to the expiry date of the group owner's account.

To see what actions can be performed on a UMG, type priv help umg.

Using UMGs

UMGs always have names of the form: "username of group owner" "+" "purpose of UMG".

For example, if user fbloggs wants to form a group with a couple of thesis partners, a logical choice of name would be fbloggs+thesis. Once created, the UMG owner (fbloggs) should create a subdirectory in their home directory for use by the UMG members and chgrp the subdirectory to the UMG. eg: % pwd /home/fbloggs % mkdir project % ls -ld project drwxr-x--x 2 fbloggs fbloggs 4096 Jan 16 13:16 project % chgrp fbloggs+thesis project % chmod g+w,g+s project % ls -ld project drwxrws--x 2 fbloggs fbloggs+thesis 4096 Jan 16 13:17 project Note that if the UMG was created (by root) after fbloggs had most recently logged in, then fbloggs will need to start a new login shell before doing any of the above, so that fbloggs' group membership may be updated to include the new UMG.

UMGs, the UDB, and expiry dates

• The UMG: fbloggs+thesis has the expiry date of 31mar2008 (matching the expiry date of its UDB entity: user.fbloggs+thesis);
• The UDB group: group.fbloggs+thesis, is a structural entity that will usually never expire;
• The two users that are members of the UMG (fbloggs and jdoe), have membership expiry dates that either preceed or equal the UMG's expiry date;

• No UMG member can have a membership expiry date that is later than the expiry date of the UMG itself.
• No UMG can have an expiry date that is later than the expiry date of the UMG's owner.

• If a UMG is about to expire (ie: the UMG user is about to expire), then as long as the UMG owner has an expiry date that is later than the UMG user, then the UMG owner may extend the expiry of the UMG to the same date as the UMG owner's expiry date by using the command: % priv umg renew UMGNAME
• If a user's UMG membership is about to expire, then as long as the UMG itself has an expiry date that is later than the UMG membership expiry date, the UMG owner may extend the membership of that user in the UMG to any DATE up to and including the UMG's expiry date by using the command: % priv umg extend UMGNAME USER DATE

Group-owned UMGs

Usually the owner of the UMG is an individual user, but it is possible for the UMG itself to be owned by a group. This means that all members of the owning group will be able to control the UMG (using the priv umg command). However, as this condition can result in no individual member of that group accepting any personal responsibility or accountability for the UMG, SS will not create such group owned UMGs unless some member of that group can adaquately justify the need for it.