A Digression into the Usage of Loopback Filesystems


A friend of mine, Brad Viviano, and I came up with the following scheme for creating a web system which allowed transparent resizing of partitions and security WRT who can mount a volume read/write and who can mount read-only. By transparent I mean to the end-user, not to someone who understands it all.

After several arguments we settled on using loopback filesystems. What this allowed us to do was have the ability to give specific users a mountable drive as read-only or read-write. This secured things between groups of users (note, not unix groups, but groups existing in society like the accounting group or the Fark project (a ficticious project name, I hope)). It also provided us with a transparent way of growing an already existing mount point. Say group Alpha and Beta decide to go in together and get a hard drive for their new websites because they didn't have the cash available to purchase drives seperately (or something). So, say the drive is mounted as "/spider1" on your server machine. In "/spider1" we would create two directories "alpha" and "beta" as the root of each group directory. Once this is accomplished, you need to decide on the heirarchy of how you want things exported. We created a directory "/web" and then created the loopbacks in "/web". This allowed us to export the loopbacks as "/web/alpha" and "/web/beta". Assuming the user takes the hint, they would create a directory called "/web" on their machine and NFS mount the drives "server_name:/web/alpha /web/alpha".

Then let's say group alpha just took off in the marketplace and the need for disk space grew by leaps and bounds. All that is needed is a new drive (/spider2) and moving the data from "/spider1/alpha" to "/spider2/alpha" and changing the loopback to be created from "/spider2/alpha" instead of "/spider1/alpha". Thus, to the end-user the change is transparent. The only repurcussion of the change is the users will have to remount the drive as they will have a stale NFS handle. Since this change would happen very seldom (if at all), it is negligible.

This is only one small example of how this works and why. The biggest advantage to using loopbacks is the security you can offer specific groups. While it isn't ironclad by any sense of the word since all someone has to do is sit down at one of the machines in group alpha, it does allow a modicum of security in the knowledge that it is "that much harder" to wreak havoc.


While it is difficult to give specific commands on how to do this on your flavor of unix, I can give you the low down in pseudo commands.

First you'll need to have a directory on a drive. It doesn't have to be a drive devoted only to this purpose. It can be any drive. The only real consideration is how important free space is on the drive. With loopbacks, any of the loopbacks can fill up any remaining amount of drive space. There is no way to control how much space a loopback takes up. For this reason, it is suggested that a drive be dedicated as that will be wanted in most cases (but not required, at all). For this example, I'll be assuming a web-like purpose.

The first drive.
So, let's take a brand spanking new 9 gig drive and mount it as "/spider1".
A couple of websites.
Let's say you have the following projects which need websites: starfury.b5.com, ea.b5.com, and minbari.b5.com.
Website directories.
You'll want each website to have it's own directory. So, create "/spider1/starfury", "/spider1/ea", and "/spider1/minbari".
Now we need the server's web hierarchy.
This is an easy one, create "/web".
Loopback time.
This is the system specific part. You need to mount, for example, "/spider1/starfury" to "/web/starfury" as a loopback filesystem. You would do this for each of the "websites" you wanted to have. Note this is not restricted to the drive "/spider1".
Exporting the websites.
Now you're ready to export the specific web directories (which are mounted loopback filesystems on the server) to the groups which need access. This is also system specific, but a common thing I won't go into.

If you want to, at a later date, move the "starfury" website onto a new drive (e.g. "/spider2") you would need to:

All "security" permissions are controlled by exporting the directory as read-only or read-write (etc) to specific machines. If you have set up apple-share or samba, then other OSs can mount these drives with the same results.

If you have any questions, problems, or suggestions please e-mail me (spowers@viviano.net).