Seamless execution mode

With a small bit of work, you can run CDE-packaged commands as though they were installed natively on the target machine, without first changing into a directory within cde-root/. Thus, the packaged commands can seamlessly interact with the user’s own files rather than running in an isolated sandbox.

Whitelist mode

If you want to run CDE-packaged commands from outside of cde-root/, you can do so by having CDE only redirect certain paths into cde-root/.

Here is how you can set cde.options (see CDE options) to make CDE operate in a “whitelist mode” where it will only redirect paths that you explicitly specify:

ignore_prefix=/
redirect_prefix=/bin/
redirect_prefix=/lib/
redirect_prefix=/usr/

ignore_prefix=/ means that CDE will ignore all paths, and the remaining options tell CDE to explicitly redirect paths within the /bin/, /lib/, and /usr/ directories. If those are the only directories that your sandboxed program requires, then it can effectively have complete access to the rest of the user’s filesystem.

This “whitelist mode” is useful when you want an application to appear as though it were natively installed on the target machine. If you set up these options properly, then you can run your executable even from outside of cde-root, as long as cde-exec and cde-root/ are located in the same directory, so that it acts like any ordinary executable on your machine.

Also, if you’re tired of typing in long paths to cde-exec, you can write a wrapper shell script using the following trick:

#!/bin/sh
DN="$(dirname "$(readlink -f "${0}")")"
$DN/cde-exec progName "$@"

If you put that script in the same directory as cde-exec, then it will set $DN to the absolute path of the directory where cde-exec is located and invoke cde-exec on your packaged program progName. The "$@" passes all command-line arguments along for the ride.

Auto-ignores

As of May 2011, you can actually invoke cde-exec from outside of cde-root/ without making any customizations in cde.options, although the above whitelist technique still works and is more robust.

If you’re invoking cde-exec from outside of cde-root/, then all non-ignored paths are first redirected into cde-root/cde-package/. If a file specified by that path actually exists, then that path is used; otherwise, cde-exec “auto-ignores” that particular path and tries to access the file natively on the target machine. The intuition here is that files that a packaged program rely on (e.g., shared libraries, configuration files) will exist in the package, but external input files (e.g., those specified on the command line) will not exist in the package and will thus be accessed from the target machine.

Debugging seamless execution mode

It can be tricky to debug seamless execution mode when things aren’t going as you expected. Here are some debugging techniques that I’ve found to be useful:

• First, remember that even though you’re invoking cde-exec from outside of the cde-root/ directory, the target program’s path must be identical to the path you used on the original machine. For example, running cde-exec /bin/foo will execute the version /bin/foo from within the package (assuming you ran cde /bin/foo on the original machine to create the package). You can even run cde-exec foo if /bin is in the version of the PATH environment variable saved in the package. (In contrast, note that running cde-exec cde-package/cde-root/bin/foo will NOT work, since that wasn’t the path you used to run the program on the original machine!)
• Run cde-exec in verbose mode using cde-exec -v, which will print out a detailed log of all paths that your program tries to access, and whether those paths are redirected within cde-root/. (Remember, if you’re running a *.cde wrapper script, you must edit it to add the -v option.)
• Manually perform delta debugging by first finding a set of options that works, a set that does not work, and then changing one option at a time until you pinpoint the source of the bug. In this case, try redirecting no paths, then redirecting all paths, then hone in on what subset of paths you need to redirect to make seamless execution work.
• Remember that the ignore and redirect path options match on simple string comparisons, so if your program issues paths via symlinks or other paths that don’t exactly match the string patterns in those options, then things won’t work as planned. Again, the -v verbose mode can help you see which paths are being redirected

Happy debugging :)