Okay, I have a vague outline of an idea for portable apps with filesystem sandboxing on Linux, using plain old chroot. Folders containing the portable apps would reside somewhere in a user's home dir, and would look like a miniature Linux root filesystem: Code: Apps/ - appname-2.2.1/ -- bin/ -- dev/ -- etc/ -- proc/ -- share/ -- sys/ -- var/ Everything would be owned by the user in question. The launcher obviously has to be a setuid root binary, or chroot won't work. It would be invoked as 'launch <appname> <app args>' by a user of the requisite group. On invocation, it would chdir to ~/Apps/appname, copy over the user's .Xauthority file, bind mount necessary virtual filesystems, and drop privileges to the limited user's via setregid() and setreuid(). Only then would it set necessary environment variables (including HOME=/), and finally invoke the application as the limited user who ran the launcher. Result, in theory: one program running as a limited user in its own little filesystem sandbox, capable of reading and modifying files within that sandbox and nowhere else. If all the requisite libraries are included it should be quite portable too. I'm thinking something like this might be useful for: - Software development. (You want an IDE running in its own environment, with none of the host system's libraries and headers.) - Web development. (You want to test a web app by running it locally.) - Running different versions of the same software. (Chroot sandbox = no conflicts.) - Running software designed for other Linux distributions. (Ditto.) - Running Windows applications securely. (Wine in a chroot sandbox, you do the math.) Does this sound sensible, or completely half-baked? What would be the possible problems with it (assuming that the setuid launcher is implemented securely, and that disk space is not an issue)?