The following details the major issue with supporting non standard locations (including standalone/USB installs) of Vivaldi for all Linux users. A follow up post will detail how it can be achieved for users with a suitable setup.
Summary of the issue
The biggest problem with running Vivaldi from a non-standard location on Linux is the related to the Chromium sandbox, a key security feature. The Chromium sandbox on Linux has historically needed to be run as the root user. This is acheived by SUID‘ing (set user ID upon execution) the sandbox application to the root (super-)user.
Depending on your Linux kernel version and its configuration, the sandbox may not need to be SUID to root any longer. Generally speaking Linux kernel’s greater than 3.17 do not. However, some distributions (like Arch) disable features such as “user namespaces” that are required to allow the sandbox to run in such a mode. We therefore provide no “official” support for non-standard install locations, since it would work for some users and not others. Such issues would likely be interpreted as bugs and cause frustration, without a lengthy explanation such as the one below.
Why did/does the sandbox ever need to run as root
The process that handles security runs as root to have sufficient rights to govern other processes and thus prevent them from doing things they should not. It is not the only security utility that works like this. Many tools that run Operating System jails or container environments have in the past (or still do) need to be run as root for similar reasons, including the classic chroot.
For those concerned about what happens within the sandbox, it is worth noting that since it is part of Chromium project, the full source code is available for inspection, review and audit. Indeed you could even compile your own and replace the one bundled with your browser.
Since it well accepted that it is best to avoid escalating privileges, the sandbox has been altered in recent times to use alternative methods, where the Linux kernel supports them. You can actually check if your browser uses the SUID sandbox method by loading vivaldi://sandbox. If “SUID Sandbox” is set to “No” and the final summary still states, “You are adequately sandboxed.” then this method is no longer being used on your system.
How this complicates non-standard installs
Since a normal install is performed as the root user (sometimes via sudo) to a shared system directory (e.g. /opt), the sandbox binary is always setup with appropriate SUID permissions. Th SUID sandbox method is then used on systems that cannot be secured by more modern methods.
Users who want non-standard installs are typically intending to run the browser from a location that is owned and limited to their normal account, either because they are not the admin on the machine or because they are not actually installing but rather unpacking the archive and attempting to run the browser directly. Both will work if they run on a Linux kernel that supports the alternative security features that the sandbox needs. However, for users running a kernel without these features the browser will not start and produce an error on the terminal, complaining about the sandbox lacking the required permissions.
Some have “worked around” this in the past by disabling the sandbox but this is a bad idea, as you are disabling a major security feature of the browser. Alternatively, a user might try to fix the permissions on the sandbox. This is only possible if you have admin rights yourself and the directory where you have Vivaldi installed isn’t mounted “nosuid” (a fairly common situation for the /home directory on some Linux distributions).
Is there any valid workaround?
If there is already a correctly setup Chromium sandbox from a system wide install of a recent Vivaldi (or another Chromium-based browser) you can tell your non-standard install to use this sandbox instead of the one bundled with it. To do so remove (or rename) “vivaldi-sandbox” from your non-standard install and define the variable CHROME_DEVEL_SANDBOX to point to the correctly setup sandbox. For example, in your “~/.bash_profile” (or another suitable location) you can define:
export CHROME_DEVEL_SANDBOX=/opt/google/chrome/chrome-sandbox
Note: You should have a recent version of this sandbox (ideally matching the version of the one bundled with the browser), otherwise you may encounter issues or it may not have received all security updates.
In a follow up post I talk about the packages we provide and the various installation options.
