1. Introduction
1.1 Who needs that
2. Principles
2.1 Non reversible isolation
2.2 Isolation areas
2.3 New system calls
2.4 Limiting super-user: The capabilities system
2.5 Enhancing the capability system
2.6 Playing with the new system calls
2.6.1 Playing with /usr/sbin/chcontext
2.6.2 Playing with /usr/sbin/chcontext as root
2.6.3 Playing with /usr/sbin/chbind
2.6.4 Playing with /usr/sbin/reducecap
2.7 Unification
3. Applications
3.1 Virtual server
3.2 Per user fire-wall
3.3 Secure server/Intrusion detection
3.4 Fail over servers
4. Installation
4.1 The packages
4.2 Setting a virtual server
4.3 Basic configuration of the virtual server
4.4 Entering the virtual server
4.5 Configuring the services
4.6 Starting/Stopping the virtual server
4.7 Starting/Stopping all the virtual servers
4.8 Restarting a virtual server from inside
4.9 Executing tasks at vserver start/stop time
4.10 Issues
4.11 How real is it ?
5. Features
6. Future directions
6.1 User controlled security box
6.2 Kernel enhancements
6.2.1 Per context disk quota
6.2.2 Global limits
6.2.3 Scheduler
6.2.4 Security issues /dev/random /dev/pts Network devices
7. Alternative technologies
7.1 Virtual machines
7.2 Partitioning
7.3 Limitation of those technologies
8. Conclusion
9. Download
10. References
Top Up

2.7 Unification


Installing a virtual private server copies a linux installation inside a sub-directory. It is a linux inside linux. If you intend to run several vservers on the same box (which you will certainly do :-) ), you will end up using a lot of disk space needlessly: Each vserver is made up hundreds of megabytes of the same stuff. This is a big waste of disk space.

A solution is to use hard links to connect together common files. Using the package information, we can tell which packages are shared between various vservers, which files are configuration files and which are not (binaries, libraries, resource files, ...). Non configuration files may be linked together saving a huge amount of disk space: A 2 GIG rh7.2 installation shrinks to 38megs.

Using hard links is cool, but may be a problem. If one vserver overwrite one file, say /bin/ls, then every vserver will inherit that change. Not fun! The solution is to set the immutable bit on every linked file. A file with such a bit on can't be modified, even by root. The only way to modify it is to turn off the bit first. But within a vserver environment, even root is not allowed to perform this task. So linked file, turned immutable, are now safe: They can be shared between vservers without side effects: Cool!

Well, there is still another side effect. All vservers are now locked with the same files. We are saving a lot of disk space, but we pay a very heavy price for that: Vservers can't evolve independantly.

A solution was found. A new bit call immutable-linkage-invert was added. Combined with the immutable bit, a file may not be modified, but may be unlinked. Unlinking a file in Unix/Linux means disconnecting the name from the data and removing the name from the directory. If the data is still referenced by one or more vservers, it continue to exist on disk. So doing "rm /bin/ls" on a vserver, removes the file /bin/ls for that vserver and that's all. If all vservers perform this task, then /bin/ls (the data) will be forgotten completly and the disk space will be recovered.

Using this trick, a vserver gets back its independance. It becomes possible to update packages by using the unlink/update sequence: Unlink /bin/ls first and then put a new copy in place. Luckily, package manager works this way.

To keep this story short (probably too late :-) ), a unified vserver:

  • Uses little disk space
  • Can't interfere with other vservers by changing one of its file.
  • Can perform package update/deletion normally using standard practice.
Top Up

One big HTML document