bug(avli): sandboxing in snap and flatpak on Linux do not allow loading temporary or persisted profiles

[blimmer]

Browsers installed with snap and flatpak sandbox the browser to certain locations on the filesystem. Therefore, temporary profiles created via mktemp or in the default persisted location (~/.config/zsh-aws-vault) fail to launch.

In these cases, we need to create the profile within the sandboxed location.

See the comment threads below where @b-anantha posted some examples.

Workaround

If you've found this bug because you're experiencing an issue, you can work around this by utilizing the "persisted profiles" configuration parameters. For example, if you're using Firefox installed via snap, you could set:

export AWS_VAULT_PL_PERSIST_PROFILE=true
export AWS_VAULT_PL_PERSIST_PROFILE_PATH=$HOME/snap/firefox/common/.mozilla/firefox

This will ensure that avli profiles are created within the snap sandbox path.

[b-anantha]

If your firefox is the snap package and you haven't mounted your tmp folder to it then it's probably complaining about that.
Creating the profile in the snap folder that firefox has access to works for me.

❯ which firefox
/snap/bin/firefox

❯ mkdir -p ~/snap/firefox/common/.mozilla/firefox/test.profile
❯ firefox --no-remote --profile ~/snap/firefox/common/.mozilla/firefox/test.profile google.com

[blimmer]

Oh, interesting. Yep, I bet that was the problem. I was using 24.10 on a UTM virtual machine, which installed it via snap. I think we'll need to add some logic to detect if it's installed via snap (maybe via which), then choose that instead of the standard TMPDIR. It's a bit unfortunate because then we can't store the persistent profiles in ~/.config...

Do you know, does this affect all browsers installed by Snap? e.g., all snap packages are sandboxed like this?

[b-anantha]

I think so since each app is meant to be in it's own isolated environment. The same is true for flatpaks and they don't work the same way as snaps.

I don't know if there is a cli way to get the profile path but going to about:profiles in the browser will show you where to create it.

❯ which firefox
/usr/bin/which: no firefox

❯ flatpak list | grep firefox
Firefox	org.mozilla.firefox	136.0.4	stable	system

❯ mkdir -p ~/.var/app/org.mozilla.firefox/cache/mozilla/firefox/test.profile
❯ flatpak run org.mozilla.firefox --no-remote --profile ~/.var/app/org.mozilla.firefox/cache/mozilla/firefox/test.profile google.com

[blimmer]

Thanks for taking the time to research this, @b-anantha. I updated the bug's title and description to cover snap and flatpak. I also detailed a workaround people can use in the meantime.

Since #43's refactors added helper functions to determine the path for the profile, I believe we can add logic to do this automatically.

Since my daily driver is MacOS and there's a workaround, fixing this isn't a top priority for me at the moment. This has been broken since before the 1.0.0 refactor, so I assume this isn't a huge problem for folks. However, I'll gladly review any PRs if folks want to attempt to fix it!