Securing your Linux lab with resettable user accounts

Reboot Restore

© Glen Lang, 123RF

© Glen Lang, 123RF

Article from Issue 107/2009

Let your lab users play, and restore the original settings for the next login.

Scenario one: You're in charge of an open computer lab at a public library. The users in the lab must have the ability to customize the computers over the course of their session, but you want to make sure any modifications they make, whether accidental or intentional, won't become permanent. The changes they make must disappear once the computer reboots so that the next user on the system will receive a "clean" home directory with the default user environment.

Scenario two: You're in charge of an open computer lab at a school. When students come in, they can sign on as either user math or english for a predefined selection of subject-related applications. As with the library scenario, the students don't have individual login names and passwords, and you don't want the students' choice of desktop or downloads to stay on the machine permanently. Every time a math student signs on as user math, the user receives a "clean" default configuration.

This second scenario describes my own work environment. As part of my job at Evergreen Valley College (San Jose, California), I administer a computer classroom with 30 dual-boot computers (Windows XP and Linux). To make sure students using Windows have a uniform experience every time they sign on, the computers have a product named Deep Freeze[1] that makes sure any changes to the computer's configuration, whether accidental or purposeful, disappear when the computer is rebooted.

When I started working in the lab, Deep Freeze did not offer a Linux version. A Linux version is available now, but it's not free (as in either speech or beer), so I decided to make a "poor man's" Deep Freeze for the Linux side of the computer lab.

More Secure Passwords

A two-letter salt encrypts passwords using DES, the least secure form of encryption, which is accepted by all distributions of Linux in the usermod command. Mandriva and Ubuntu will accept encryption in the MD5 format. To produce an MD5-encrypted password, use a salt that begins with $1$, followed by exactly eight characters. Below is the output of the encryption for user math using MD5 and an arbitrary eight-letter salt:

$ perl -e 'print crypt("counting","\$1\$jwyxngms"),"\n"'

How It Works

First, create a compressed file containing the image of the home directory of each Linux user you want restored at reboot time. (In the example of the computer lab, there will be two image files, one with the clean desktop for user math and one for user english.)

Then set up a configuration file that gives that user's name, an encrypted password, and the location of the compressed image file. At boot time, an init script calls a Perl program to restore the user.

Creating the Student Image

On one machine, designated the "master copy," adjust the configuration (desktop, menus, applications, etc.) for each student to the state desired. Here's the tricky part: You can't compress the student's home file while signed on as that student. Instead, you want to be alone on the machine. Pressing Ctl+Alt+F1 drops you into a text-only terminal. To go to single-user mode, log in as root and then type:

init 1

When in single-user mode, you are the root user, the network isn't running, and you are guaranteed that the user whose files you are compressing isn't online.

Now create images of the user directories you want restored at boot time. If your computer lab has separate accounts for math and english users, use tar to create a compressed image for each:

tar -cvzf math_home.tar.gz /home/math # gzip form
tar -cvjf english_home.tar.bz2 /home/english # bzip2 form

Of course, you probably want to use the same archive format for all the users you want to restore, but I wanted to show an example of both forms. The name of the compressed image file must end with .gz or .bz2 or the restore program won't work properly. In my lab, the average size of each user image file is about 2MB.

Local or Remote

Either you place the image files on a server or you copy them to each machine. The advantage of the server is that you need to put the files there only once; the advantage of placing them on each machine is that you do not need to depend on a network connection that might be down or have a slow transfer rate.

In most cases, you will probably place your image files on the server. For my lab, it was more advantageous to copy the files to each of the machines. If you are installing the images on each machine, you probably want to upload the image to a server somewhere and download it to each machine via FTP or wget. Also, you could copy the image files to a USB stick and then copy them to the individual machines.

Buy Linux Magazine

Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

  • Qt4-fsarchiver

    Qt4-fsarchiver lets you back up files, complete partitions, and create disk images with a single mouse click.

  • Mondo and Mindi

    Mondo shows that backups don’t need to be time consuming or difficult. This amazingly simple tool backs up complete hard disks or individual directories.

  • System Recovery with tar

    Use a tarball to restore your system in next to no time – without a complete re-install.

  • Clonezilla SE

    Managing a network of computers can be an involved process. Clonezilla SE lets you image and roll out multiple machines with ease.

  • Partimage

    Protect your system and preserve your configuration with this powerful backup tool.

comments powered by Disqus
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters

Support Our Work

Linux Magazine content is made possible with support from readers like you. Please consider contributing when you’ve found an article to be beneficial.

Learn More