Privileges and Access Control

Autolab is hosted in CMU's AFS file system within the CS.CMU.EDU realm. Access is via your Kerberous account. Because we operate out of the CS.CMU.EDU realm you will need CS tickets to access the Autolab files. If your account is @cs.cmu.edu then you already have this. @andrew.cmu.edu accounts will need to first run

$ aklog CS.CMU.EDU

Autolab itself runs on a service principal academic.autolab and is authenticated via a keytab.

The following PTS groups are used to controll access for human users:

• academic:admin.autolab The administration group. This group has access to the production directory of Autolab.
• academic:developer.autolab The developer group. This group has permission to check out and check in code to the development repositories.

Checking the membership of a group can be done (from an Andrew server) with:

$ pts membership academic:developer.autolab -cell CS.CMU.EDU

You can add an account to a group with:

$ pts adduser newdev@andrew.cmu.edu academic:developer.autolab -cell CS.CMU.EDU

You can remove an acount from a group with:

$ pts removeuser baddev@andrew.cmu.edu academic:developer.autolab -cell CS.CMU.EDU

Access to Greatwhite. The Autolab frontend machine is greatwhite.ics.cs.cmu.edu. Access is limited to Autolab developers and course staff.

To add a new user on greatwhite, use the visudo command to modify the AllowUsers field in /etc/ssh/sshd_config, followed by service sshd restart make the change take effect.

Root control of greatwhite is with sudo. Use the visudo command to edit the sudoers file. Root access should (of course) be extremely limited.

Access to other local files on greatwhite is controlled with the autolabDev group. The usermod

command can be used to add and remove a user from groups:

$ sudo usermod -a -G autolabDev userid