Fatdog (since version 520) comes with a sandbox tool built-in. The tool is activated through terminal - there is no menu or GUI for this. The commands are:
sandbox.sh and rw-sandbox.sh are identical, except that sandbox.sh stores the content of the sandbox session in tmpfs (therefore it's not persistent), while rw-sandbox.sh stores the session in a file. An analogy with running Fatdog would be:
In the following description, all references to sandbox.sh also means rw-sandbox.sh except when noted.
The sandbox is meant for:
Sandbox is the solution to this. The sandbox creates an environment which is similar to the currently running system, but is safely separated from it. Any changes made to the files inside the sandbox (with few exceptions) will not affect anything outside. One can thus start the sandbox, install any number of packages in it, test them, and when done, leave the sandbox - and everything will be restored.
The usual steps for packages that uses autoconf are:
But this has obvious limitations. For one, it only works with packages that uses autoconf as its build system. Secondly, not all packages act kindly with new2dir - they don't always work. For example, python packages can't be captured this way. Other build systems (cmake, jam, etc) also can't be captured this way.
Sandbox provides a solution to this. A package can be configured, built and installed in the sandbox - without any use of Puppy's specific tools. Once this is done and the package is confirmed to work, all that is left to do is to scrape the files that were changed and installed - and the sandbox makes this super easy. In fact, the third command in the sandbox package (pet4sand.sh) will do this automatically. Supply it with a name (any name that is acceptable to dir2pet) and it will look at all the changed files from the sandbox, copy them over, and create a .pet package.
Start the sandbox by running sandbox.sh. A dialog box will be shown, showing all the currently mounted SFS (this includes Fatdog's save file, Fatdog's main sfs, and any other SFS currently mounted). One can choose which SFS will be loaded into the sandbox. If the SFS is not chosen, they won't be loaded and won't be visible. For example, for testing packages in pristine conditions, one can choose not to load the currently used save-file. The sandbox environment will then be almost identical to running Fatdog with pfix=ram.
rw-sandbox.sh behaves identically - except that, first, it will ask the user where to store the permanent session file (="the savefile").
Once inside the sandbox, one can do almost everything that one can do in the system itself. Running terminal commands obviously work. Running GUI programs will work.
In addition, the sandbox comes with a full Xorg emulation environment - this can be started by typing "xwin" inside sandbox. A nested X server windows, complete with its own instance of openbox, rox and lxpanel.
A few exceptions:
Note: if one wishes to run "rox" without the full Xorg emulation environment, one has to use "-n" parameter to start it, like "rox -n".
Once done, type "exit" inside the terminal that contains the sandbox. If one uses the full Xorg emulation, close the window that contains the emulated Xorg - don't choose any of the menus to reboot/shutdown from the inside.
The sandbox is implemented using stackable union file system, aufs, just like the main Fatdog. All the files modified in sandbox is visible in /mnt/sandbox (this mountpoint only exist when sandbox is running). The sandbox's fake root, i.e. the top of the union seen from within the sandbox itself is mounted as /mnt/fakeroot.
There can only be one and only one sandbox running at one time (regardless of sandbox.sh or rw-sandbox.sh). Running more than one is untested and will probably crash and/or corrupt your system.
The sandbox is not a security tool, and is never intended to be. Some of the files changed in the sandbox do propagate to the system outside. For example, /tmp directory from the system is mapped to the sandbox. Any changes made to /tmp will be visible and have direct effect to the system outside. The same can be said for /proc and /sys - thus all process currently running in the system can be seen within the sandbox. Running "wmreboot" from within the sandbox will shutdown the entire system, not just the sandbox. This is a design choice. The built-in sandbox is meant for testing, not for security.