Project Groups

The Group Mechanism

As an instructional aid, project leaders may designate TAs to lead smaller groups of project members. This is accomplished by creating a group, and designating the TA as the leader of that group. A project group is a lot like a unix group, and in fact unix groups is the mechanism used to protect members of one group from members of another group on Emulab nodes. For each group created, a new unix group is created, and the members of the group added. When a group member starts an experiment, he/she indicates the group in the Begin Experiment form. All of the nodes in the experiment will have user accounts built for only those members of the group. In this way, multiple groups of a project can work independently, and be protected from each other via the generally well understood unix group protection mechanism.

The Default Group and Subgroups

As a convenience, all new projects are created with one new group, termed the default group. All project members are in the default group, and as its name implies, whenever the group is left unspecified in a form, it defaults to the default group (this allows you to create a project without any additional groups at all; new members join the default group, new experiments are created in the default group, etc.).

Subgroup is used to refer to a group in a project which is not the default group.

Project Leader Privileges

As project leader (proj_root or group_root in the default group), you may create and destroy subgroups, and add or remove project members from any subgroup. You can also edit the personal information for group members, and begin and terminate experiments in any group. You have root access on every experiment node in any group in your project. You can make yourself the leader of new subgroups, but more typically you would designate someone else to lead a subgroup. A project leader has full control over a subgroup regardless of whether he is a leader, or even member of that subgroup (in fact, it may be desirable to not be a member of subgroups, since subgroup membership means your home directory will be available on nodes on experiments in that subgroup.)

To create a subgroup, simply go to the Project Information link at your left, and look for the "Create New Group" link, or go to the Create New Group page directly. Once you have created a subgroup, you can edit its membership by clicking on the "Edit" option in the group information page.

Group Leader Privileges

As group leader (group_root) in your group, you may approve new user applications to join your group, as well as remove users from your group. You may bestow group_root, local_root, or user privileges on other users in your group. You may begin and terminate experiments in your group, and have root access on experiment nodes in your group.

If you are a TA managing a subgroup, you can have new Emulab users Join your subgroup by telling them to go to the Join Project link at your left, and specifying the name of your subgroup where it asks for a group name. You will receive an email message for each person that applies to join your subgroup. To approve (or deny) membership in your subgroup, use the New User Approval link. If the user who wishes to join your subgroup is not already a member of the project, approving them to join your group will automatically add them to the project, with user permissions in the default group.

Note: There is no mechanism to join multiple subgroups via a single web form, however, once you have joined one group in a project, you may submit group join requests multiple times to join other Project groups.

Note: Only the project leader may give users group_root in the default group.

Local Root Privileges

As Local Root (local_root) in a group, you may not alter the membership of the group in any way. However, you may begin and terminate group experiments, and have root access on experiment nodes in your group.

User Privileges

As a user (user) in a group, you may not alter group membership or begin and terminate group experiments. You may, however, log into nodes in group experiments, without root access.

Security issues

These are some important security issues to keep in mind:

• Unix groups are used to protect members of one group from members of another group. Users may create shared directories by using the unix chgrp command. When accounts are created on the experimental nodes after a new experiment is started, only those members of the group will get accounts on the nodes; other members of the same project, not in the group, will not get accounts.
• Emulab uses NFS mounted filesystems for /users, /proj, /groups, and (optionally) /scratch on the experimental nodes. Because of the nature of NFS, giving root privileges to a user will allow them to read/write any files on any filesystems that are mounted, since root access allows them to su as any other user. Thus, any files in the project directory and in the home directories of other members of the group, can be can be "compromised" by a group member. Please note that no other directories are NFS mounted; other projects and users on Emulab are safe.
• For each group, a separate directory is created, named /groups/projname/groupname. This, and only this directory in /groups, is exported to the nodes of experiments created within the group (the group option in the Begin Experiment page). Thus, even though users might have root access on the experimental nodes, the only directory in /groups/projname they will have access to is their own group directory. Any files that need to be private to the group, should be placed under /groups/projname/groupname. This ensures that each group has a private place in which to store files that group members want to share with each other. Remember, tell your project members that they should not use /proj or their home directory to store files they want to keep private.
• It is forbidden to grant root (project_root, group_root, or local_root) permissions to a user in the default group and user permissions in a subgroup, as it can result in an unintentional breach of privacy.
  • Consider this example: User Joe has local_root permissions in the default group, and user permissions in a subgroup. Another user Bob is in the same subgroup as Joe, and since Joe has user permissions, it was probably intended that Joe would not be able to read Bob's files. Joe now creates an experiment, specifying the default group in the web form. The nodes in Joe's experiment would get NFS mounts for all of the members in the project (including Bob), and since Joe has local_root permission in the default group, would be granted root access on his nodes. Joe can now access the files of all members of the project, including Bob. The correct approach is to specify user permissions in the default group, and either user or local_root in the subgroup (depending on whether subgroup members are mutually trust each other and need to create experiments).
• Also disallowed is specifying different levels of trust (some root, some not) for a user who is in multiple subgroups of a project. In this case, any other users that are in the same subgroups (overlapping) are potentially at risk.
  • For example, if Joe has group_root permissions in one subgroup, and user permissions in a second subgroup, and there is another user Bob who is in both subgroups, then Joe can access Bob's files when creating an experiment in one of the subgroups, but not the other. If Joe is really not supposed to access Bob's files, then Joe should not have group_root permission in a subgroup that contains Bob.

Trust option summary