Jails

Jails

A fundamental feature of the new framework that varies from many other frameworks, at least in terms of increased security, is the concept of “jails”. Jails provide a way for modules to be completely isolated from eachother, and modules may eventually be chrooted into their jail directories in a production configuration. Jails are created in jails/, and are created only once you start a module. Each module gets it’s own folder, which is completely isolated from all of the other modules. Modules should not attempt to break out of their jail, and should communicate only through their shared data folder. Each jail looks something like this, with the events jail being used as an example:

run (script)
tmpl/
    mobile/
    desktop/
bin/
    events
log/
    Sunday, April 3 2010
data/
    shared/
    img/
    css/
    js/
    tmpl/

Obviously, this is a simplified example. I only show the important parts here, not every single file. In general, you don’t need to know that much as a casual programmer other than that the program’s jail is different from the program’s source folder, and that the files are in no way guaranteed to be consistent. You must restart the module for your changes in the source tree to show up in the jail on systems that do not support inotify, and for actual changes to the source you have to recompile or compile first. Although this can be annoying, it ensures that the framework never messes with your source files, and keeps your actual module folders clean.