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 (sb2dir.sh - sandbox-to-directory) will do this automatically. Supply it with a directory name and it will look for all the changed files from the sandbox, copy them over to "/tmp/dir-name-that-you-give". All you need to do afterwards is to check the files inside, once you are happy with it, just run makepkg inside on that directory.
Application installation usually places files in many places in the filesystem. After the application is run, it also creates configuration and other files, in a way. If you need to install many applications, but they are only used very rarely, it is easy to grow your savefile to become very large and cluttered with all these applications. Some applications offer "portable" versions and can be installed in one directory, but many are not. Is there a way around this?
Or you may want to install an application but run it with different or multiple configurations, which isn't supported natively. You can switch config files back and forth to do this, but is there an easier way?
Of course: use the sandbox! Starting from version 622 onwards, multiple sandboxes can be run at the same time, making it an ideal way to isolate applications. Create an rw-sandbox for every application you want to isolate. Install the application from within the sandbox, and then run it. When you're done, close the sandbox. This way, you can have a rw-sandbox for each application. You can even have multiple sandboxes for the same application, each with different configuration. Need to configure and keep different versions of the same application? No problem too!
Note: This only works for "well-behaved" application - that is
application which do not pose security risk to your system. The sandbox is not a security
tool. It is still possible for malicious apps to create
havoc on the system. It is possible for malicious application to
"escape" from the sandbox. If you need to secure yourself from
these, you need a stronger sandboxing: consider using Linux Container sandbox or User
Mode Linux or other virtualisation solutions such as Qemu
(with/without KVM), VirtualBox, or others.
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 savefile=none.
rw-sandbox.sh behaves identically -
except that, first, it will ask the user where to store the
permanent session file (="the savefile"). You can also pass the
path to the "savefile" as the first parameter to rw-sandbox.
From Fatdog64 720 onwards, you can pass the command to be
executed in sandbox by as an argument to sandbox.sh or
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 desktop emulation environment - this can be started by typing xwin inside sandbox. A nested Xorg server (Xephyr), complete with its own instance of openbox, rox and lxpanel will launch.
Note: if one wishes to run "rox" without the full desktop emulation environment, one has to use "-n" parameter to start it, like this: rox -n.
Once done, type "exit" inside the terminal that contains the sandbox. If one uses the full desktop emulation, close the window that contains the emulated Xorg or choose Exit to Terminal or Restart X server from inside the sandbox's desktop.
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/sb/sandbox (this mountpoint only exist when sandbox is running, it is also the sandbox-path you need to pass to sb2dir.sh). The sandbox's fake root, i.e. the top of the union seen from within the sandbox itself is mounted as /mnt/sb/fakeroot. If you run multiple sandboxes, the sandbox and the fakeroot will be /mnt/sb/sandbox.XXXXXX and /mnt/sb/fakeroot.XXXXXXX respectively, where XXXXXXX is a random string.
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 no longer true in version 622 onwards, but only because "wmreboot" script is overwritten. Running "reboot" will still reboot the entire system).
Standard sandbox uses chroot as its
isolation mechanism. sandbox-lxc is a sandbox that uses Linux Container instead
of chroot. Linux Container (LXC) a process isolation mechanism,
similar to FreeBSD
jail (and Virtuozzo, OpenVZ (open-source version of
Virtuozzo), as well as Linux-VServer). From Fatdog64 700
on-wards, suitable kernel is provided and the necessary CLI
tools are included in the distribution. Older Fatdogs requires
installation of supporting utilities and specially configured
sandbox-lxc provides more isolation than standard sandbox :
Differences from usage perspective:
Please note that LXC is still in active development and there
may be issues that affect isolation. If you really need even
tighter security controls then please consider User Mode Linux or KVM/Qemu or other
full-system virtualisation solution.
From Fatdog64 720 onwards, sandbox-lxc also supports running
one-time command by passing the command as sandbox-lxc (and
rw-sandbox-lxc) arguments. Unlike the normal sandbox,
however, which runs the command and then quit, in sandbox-lxc the
command is executed (after rc.sysinit.lxc has been executed)
and then it returns to sandbox shell. If you want to
explicitly terminate sandbox-lxc afterward, you must issue
"poweroff" as one of the command sequence.