By default, when you reserve the lab for Linux or Labtest mode, your booking will have no user restrictions. That is, any student can login to any lab machine including students who are not part of your course. Ultimately, this is the simplest setup as once you enable user restrictions, there is always the potential to inadvertently restrict students from logging in who should otherwise be able to login! As a result, if you wish to have the ability to restrict access to the lab machines to specific students, you must make this part of your booking request.

Once tech has enabled “user restrictions” on your lab booking, the next step is for you to configure it. To do this, place a file called users.allow in your course directory - /eecs/course/<COURSE>. This file contains one user who is allowed to login per line. For example, if only cse1234 and cse5678 are allowed to login during your booking for EECS9999, then /eecs/course/9999/users.allow would contain:

cse1234
cse5678

IMPORTANT NOTE: The users.allow file must be readable by the system, or it will be ignored and your restrictions will not be followed. To make the users.allow file for EECS9999 readable by the system: chmod o+r /eecs/course/9999/users.allow

When the machines boot into Linux or Labtest mode, a “RESERVED” message will appear on the bottom of the login screen. If a student who is not in the allow list tries to login, he will see a message as follows:

The computer that you are trying to use has been reserved and 
is not available for your use at this time.  Sorry for any
inconvenience.

The users.allow file may also contain an optional “#include” directive. For example:

#include /eecs/course/9999/users.contest
#include /eecs/course/9999/otherusers

NOTE: There used to be a “#includedist” directive which would allow you specify a distribution list. Distribution lists are no longer available in labtest mode, and hence this does not work. An alternate solution is provided below.

If your lab booking includes multiple machines, and you wish to restrict different users logging into different machines, this functionality is available as well. Simply append “.<HOSTNAME>” to the users.allow file in your course directory to restrict users to a specific host. For example, assume that you are teaching EECS9999, and have booked machines ea01 through ea10. You want to restrict “cse1234” to logging into host “ea01”, “cse5678” to logging into “ea02”, but your other students “cse91011” and “cse91112” can login to any other ea host. To do this, create /eecs/course/9999/users.allow.ea01 and put in it:

cse1234

Create /eecs/course/9999/users.allow.ea02 and put in it:

cse5678

Create /eecs/course/9999/users.allow and put in it:

cse91011
cse91112

If you want to allow access to your test to only users who are enrolled in your course, then you can extract this information from the distribution list prior to your test. For example:

% awk '{ print $1 }' /eecs/dept/dist/EECS9999 | grep -v "<NO-CS-ACCT>" > /eecs/course/9999/users.allow
% chmod 644 /eecs/course/9999/users.allow

If you wish to test whether a user will be able to login during your lab booking, you can use the pcmode-allow command. This is the identical command used by the system during login to verify whether a user should be able to access a given machine. For example, assume that your booking has ID 6 (as per the pcmode schedule), and you want to check whether a user “cse1234” will be able to login to “ea01” during your test. Execute the pcmode-allow command as follows:

% /xsys/pkg/pcmode/bin/pcmode-allow cse1234 6 ea01

Proper responses will be one of:

• user cse1234 does not meet pcmode access restrictions in /eecs/course/9999/users.allow for host ea01 id 6 and cannot login.
• user cse1234 does not meet pcmode access restrictions in /eecs/course/9999/users.allow.ea01 for host ea01 id 6 and cannot login.
• user cse1234 meets pcmode access restrictions in /eecs/course/9999/users.allow for host ea01 id 6 and can login.
• user cse1234 meets pcmode access restrictions in /eecs/course/9999/users.allow.ea01 for host ea01 id 6 and can login.
• warning: found no system readable restriction file for id 6 - everyone will be allowed access
• [if cse1234 was in either group tech/faculty/submit]: user cse1234 is a member of a system group exempt from pcmode access restrictions for host ea01 id 6 and can login.

NOTE:

• Users who are in the tech, faculty, and submit system groups are automatically exempt from login restrictions. These users do not need to be included in your users.allow file.
• If you have an empty users.allow file, then nobody can login (except as indicated above).
• If your users.allow file is missing, this has the same effect as no restriction at all - anyone can login.
• users.allow and users.allow.<HOSTNAME> files are totally independent. If a users.allow.<HOSTNAME> file exists for a host, it will always be used instead of users.allow.
• If a student was forgotten from users.allow or a guest student showed up, you may edit users.allow during the booking to correct the issue.
• The permission of the users.allow file is very important. It must be readable by the system. For example: chmod 644 users.allow. If you make the users.allow file writable by submit group, then your TA (who would normally be in the submit group) should be able to fix any last minute mistakes during the lab session.
• At this time, users restrictions are available for Labtest or Linux modes, but not Windows.
• Please note that if you enable user restrictions on your booking, you need to be extra careful to ensure proper syntax in users.allow, and that your users.allow file includes ALL users who need to login. TAs need to be aware of user restrictions so that they do not panic if a student is unable to login.