groups.html 6.67 KB
Newer Older
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
<center>
<h2>Project Groups</h2>
</center>

<p>
As an instructional aid, project leaders may designate TAs to lead
small groups of project members. This is accomplished by creating a
<em>group</em> (sometimes referred to as a "subgroup"), and
designating the TA as the leader of the 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 subgroups
of a project can work independently, and be protected from each other
via the generally well understood unix group protection mechanism.
</p>

<p>
22 23 24 25 26 27 28 29 30 31 32
As a convenience, all new projects are created with one new group,
termed the <em>default group</em>. 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 project group (this allows
you to create a project without any sub groups at all; new members
join the default group, new experiments are created in the default
group, etc.).
</p>

<p>
As project leader, you may create and destroy subgroups, and add or
33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63
remove project members from your groups. You are automatically a
member of new groups you create; even though you are not the
designated leader of the group, you still retain all of the same
permissions that you have as project leader, within the group. This
means that you can terminate experiments that have been created within
the group, and edit the personal information for group members. To
create a group, simply go to the Project Information link at your
left, and look for the "Create New Group" link, or go to the <a
href=https://www.emulab.net/newgroup_form.php3>Create New Group</a>
page directly.  Once you have created a group, you can edit the
members of the group by clicking on the "Edit" option in the group
information page.
</p>

<p>
As group leader, you may approve new user applications to join your
group.  You may also create and destroy experiments created within the
group. If you are a TA managing a group, you can have new Emulab users
<em>Join</em> your group by telling them to go to the <a
href=https://www.emulab.net/addusr.php3>Join Project</a> link at your
left, and specifying the name of your group where it asks for a group
name. You will receive an email message for each person that applies
to join your group. To approve (or deny) membership in your group, use
the <a href=https://www.emulab.net/approveuser_form.php3>New User
Approval</a> link. If the user who wishes to join your group is
already a member of the project, then the project leader must add them
to your group. In other words, there is no mechanism to join multiple
groups via a web form; the Project Leader must do it on the Edit Group
page.
</p>

64
<a NAME="SECURITY"></a>
65
<p>
66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119
<b>
These are some important security issues to keep in mind:
</b>

<ul>
<li>
Unix groups are used to protect members of one group from members of
another group. Users may create shared directories by using the unix
<tt>chgrp</tt> 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.

<li>
Emulab uses NFS mounted filesystems for <tt>/users</tt> and
<tt>/proj</tt> on the experimental nodes. Because of the nature of
NFS, giving root privledges to a user will allow them to read/write
any files on any filesystems that are mounted, since root access
allows them to <em>su</em> 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.

<li>
It is important to remember that granting "root" permissions to a user
in the project (or default group) and "user" permissions in a
subgroup, is inconsistent and can result in a breech of privacy.
Consider this example; user Joe has "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 "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 "root" in the subgroup
(depending on whether subgroup members are mutually trust each other
and need to create experiments).

<li>
Equally dangerous is specifying different levels of trust for a user
that is in multiple subgroups of a project. In this case, any
<em>other</em> users that are in the same groups (overlapping) are
potentially at risk. For example, if Joe has "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 "root" permission in a subgroup that contains Bob.

</ul>
120

121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149
<table cellspacing=2 border=0>
        <tr>
            <td colspan=4>
                <h4>You have the following choices for <b>Trust</b>:</td>
        <tr>
        <tr>
            <td>&nbsp</td>
            <td>User</td>
            <td>-</td>
            <td>User may log into machines in your experiments</td>
        </tr>
        <tr>
            <td>&nbsp</td>
            <td nowrap=1>Local Root</td>
            <td>-</td>
            <td>User may create/destroy experiments in your project and
                has root privileges on machines in your experiments</td>
        </tr>
        <tr>
            <td>&nbsp</td>
            <td nowrap=1>Group Root</td>
            <td>-</td>
            <td>In addition to Local Root privileges, user may also
                approve new group members and 
                modify user info for other users within the group. This
                level of trust is typically given only to TAs and the
                like.</td>
        </tr>
      </table>