Looking for a "staging area" app sandbox to test apps

alsr · 2020-04-25 19:09:03

I would like to keep my home directory clean and somewhat representative of the apps that I have decided on using, that I have settled on as the best for my style and taste in their categories. Actually, the same goes for my app menus and installed packages.

Let's say I'm looking for a tabless web browser... I'd probably look in AUR and the Arch Wiki page on browsers, and install and test out a bunch of them, whether from the main repos, or from the AUR. Then I'd pick one. Is there anything that I could install that would somehow segregate all of these apps, short of a full-fledged VirtualBox or something, to create a sort of sandboxed staging area, where it would get installed into some environment that it believed was normal, and from the app's perspective it could write itself and its config files to the filesystem like /etc and my homedir as normal, but actually it would be writing into something like ~/sandboxdir/.config/{surf,vimb,etc}.cfg? I suppose that in the design which I imagine, there would also need to be some way of accessing a combined application menu where ~/sandboxdir/ might have a sub-path which could have .desktop files placed into it, and then I might be able to access an application menu somewhere that would contain all of my canonically system-installed apps reconciled with my staging sandbox-installed ones, with the latter category somehow indicated as such with an italicized menu item or possibly a different colored highlighting, etc...

Obviously if something like this existed, it wouldn't necessarily be designed exactly how I've imagined that such a tool would be structured, but does anyone know of anything to this effect?

TIA!

jsoy9pQbYVNu5nfU · 2020-04-25 19:31:22

You want to leverage user/mount namespaces (see man 7 namespaces) and overlays, bind mounts etc.

A tool that makes this workable and configurable very simply is firejail. It has comprehensive capabilities but is easy to use. For example, you can define an overlay on the command line with --overlay-tmpfs or in a automatically invoked app profile that can make all ad-hoc settings persistent. This is probably the most simple and quick solution for you if you don't know much about containers, namespaces and such.

Slightly different semantics and feel of use are offered by systemd-nspawn.

More heavyweight solutions like podman and dockerd would offer yet another approach, mostly being more streamlined in how they offer ways to persist data outside of the container/sandbox and more flexible in how they do e.g. networking.

All the tools mentioned are in the official repos, have good upstream documentation as well as Arch wiki articles, except for podman, but there RedHat has really comprehensive documentation.

Last edited by jsoy9pQbYVNu5nfU (2020-04-25 19:31:50)

alsr · 2020-04-25 22:22:18

Hi, thanks for all of this information!

Was just wondering, do you know of any graphical solutions? Something analogous to Sandboxie for Windows comes to my mind...?

alsr · 2020-04-25 22:32:43

My main concern isn't security (I don't plan on trying out apps that I don't trust to be secure), but cluttering up my home directory with configuration profile files/folders from apps that I just tried once and don't actually want or use. I'd like it to stay clean and tidy so I can see easily what's what and find what I need quickly. In fact, ideally I think I'd like the apps to be able to read the rest of my filesystem to access the shared system files and package dependencies that they need (like /etc/hosts, for example, which any linux app may reasonably be expected to expect to be present on a running host system), just that they'd be installed in some secluded way. Or it would probably be simpler if they were installed with some kind of tag in the package manager to indicate that they're only being installed for "testing purposes" (or maybe they just get installed for a aspecific user, or they are installed globally but only usable by a specific user), and then it's easy to quickly uninstall all apps that are marked as installed only for testing purposes, along with all of the configuration files that they created and left behind? (That is the main function I want, really.) Or, alternatively they could be "unmarked" as experimental so like "committed" into my family of embraced applications. But the second operation is not so important because I could simply nuke the staging area and then reinstall the app without the "experimental" flag/marking...

Does pacman have any functionalities like this? Can you think of any other solutions that achieve this? Or would you still stand by your previous recommendations?

Thanks again

alsr · 2020-04-25 22:35:04

Maybe the play is to firejail a login session of a "tester" user each time I want to go "shopping" for applications for a given use case and the install all of the apps from within that login session?

Trilby · 2020-04-25 22:49:56

For your goals, a secondary (even temporary) user would be best. There is no simple way to flag a package in the pacman database in the way you described, but more importantly, even if you could, that wouldn't help you remove config files and other data in the home directory. You can just keep a list of packages you've installed to test with a test user. In other words:

1. Create user tester
2. Create file in tester's home directory 'packages' and append the name of each testing package to it
3. Play around with packages
4. When done, `pacman -Rsn - < /path/to/testerhome/packages`
5. Remove tester user

You could even set 'tester's home directory to be in tmpfs if you want a clean slate for the tester after each reboot (though you'd then have to keep the package list somewhere else).

alsr · 2020-04-25 23:31:21

Trilby wrote:

For your goals, a secondary (even temporary) user would be best. There is no simple way to flag a package in the pacman database in the way you described, but more importantly, even if you could, that wouldn't help you remove config files and other data in the home directory. You can just keep a list of packages you've installed to test with a test user. In other words:
1. Create user tester
2. Create file in tester's home directory 'packages' and append the name of each testing package to it
3. Play around with packages
4. When done, `pacman -Rsn - < /path/to/testerhome/packages`
5. Remove tester user
You could even set 'tester's home directory to be in tmpfs if you want a clean slate for the tester after each reboot (though you'd then have to keep the package list somewhere else).

Hmm, nice idea, Trilby!

A couple questions...

Would this solution allow for "testing" AUR packages?

Also, ... I'm not really fussed whether it gets nuked so regularly as every reboot, or every logout of tester, or whatever else have you, as long as I have a simple way to nuke all of the staging area marked packages when things begin to get cluttered in my app menu from installing 10 apps each in every genre that I want to find something suitable in. That said, is there any record kept of the user responsible for installing each individual package? In that case, I could simply query the logs or database for all packages installed by user "tester". Alternatively, could I engineer any such record to be kept? Like a user-specific pacman configuration file in ~tester with a hook of some sort for pacman to echo the package name into a log file as you suggest so that it needn't be manually kept? Or perhaps the move is a wrapper function for pacman in ~tester/.bashrc that runs pacman in an appropriately configured firejail command?

From my own research, it seems actually that `mbox` [1] is virtually exactly what I'm looking for, or perhaps I should alas say "was."

Mbox introduces a novel sandbox usage model; when executing a program in the sandbox, Mbox prevents programs from modifying the host filesystem while giving them the impression that they are in fact making those modifications. Mbox achieves this by providing a layered sandbox filesystem and by interposing on system calls with ptrace and seccomp/BPF. At the end of program execution, the user can examine changes in the sandbox filesystem, and selectively commit them back to the host filesystem.

Its -i flag in particular seems to be the exact function I'm looking for, and if it hadn't been abandoned, I would probably run it in my own user profile and create an alias called "stage" for mbox -i -- pacman.

[1] https://pdos.csail.mit.edu/archive/mbox/

Trilby · 2020-04-25 23:42:59

alsr wrote:

Would this solution allow for "testing" AUR packages?

Once built, a package is a package. So yes.

alsr wrote:

That said, is there any record kept of the user responsible for installing each individual package?

Packages are only installed as root. So no.

alsr wrote:

Alternatively, could I engineer any such record to be kept? Like a user-specific pacman configuration file

A user-specific config would be a very bad idea. But you could easily make a shell function to log installs, e.g.

pacman() {
   case $1 in
      -S*) /bin/pacman $@ && shift && echo $@ >> ~/package.list ;;
      *) /bin/pacman $@ ;;
   esac
}

Then when you are done with that user: `pacman -Rsn - <~/package.list

But is this really your main concern:

alsr wrote:

when things begin to get cluttered in my app menu ...

If that's the case, this is an X-Y problem, there aremuch easier solutions. Just customize your menu, or set up ~/.local/share/applications/ appropriately.

alsr · 2020-05-01 11:30:57

Well, no, that was one example of the fundamental problem. Ideally, I would like to only install packages onto my system that I have reviewed and decided I approve of and like and want to embrace. But there's no way to try out and find such applications without installing the apps in some way. There are several symptoms of unwanted applications being installed that haven't passed my test... One is cluttered applications menus, another is cluttered homedirectory config/profile files/dirs, and another is the pacman database of installed packages. I would like to at any time be able to back up my home directory as well as a generated list of installed packages to be able to reproduce my current system at any time. The trouble with installing new apps to be tested as a dedicated user and then uninstalling them when done testing is that sometimes things come up and one needs to leave one's task, and if one must go and do something else in the middle of testing a bunch of browsers or spreadsheet editors, then one would leave with a bunch of unwanted apps that one may not even know from just seeing the name later on in the future are browsers or spreadsheet editors. Also, it would require one to switch users in order to test a bunch of new apps.

I would much rather have them all in a segregated sandbox space, a staging area, until I manually "bless" each one into the canonical system.

That said, I've found the following in firejail's documentation which seems perfect, and made for this exact use-case! [1]

3.3 OverlayFS

One use case for Firejail’s OverlayFS front-end is testing new software packages. All filesystem modifications performed while installing and running the software are stored in overlay layer. The host filesystem is not touched.

[1] https://firejail.wordpress.com/document … #overlayfs

Arch Linux

#1 2020-04-25 19:09:03

Looking for a "staging area" app sandbox to test apps

#2 2020-04-25 19:31:22

Re: Looking for a "staging area" app sandbox to test apps

#3 2020-04-25 22:22:18

Re: Looking for a "staging area" app sandbox to test apps

#4 2020-04-25 22:32:43

Re: Looking for a "staging area" app sandbox to test apps

#5 2020-04-25 22:35:04

Re: Looking for a "staging area" app sandbox to test apps

#6 2020-04-25 22:49:56

Re: Looking for a "staging area" app sandbox to test apps

#7 2020-04-25 23:31:21

Re: Looking for a "staging area" app sandbox to test apps

#8 2020-04-25 23:42:59

Re: Looking for a "staging area" app sandbox to test apps

#9 2020-05-01 11:30:57

Re: Looking for a "staging area" app sandbox to test apps

Board footer