#!/bin/bash if type update-alternatives >/dev/null 2>&1; then # Remove previous link if it doesn't use update-alternatives if [ -L '/usr/bin/${executable}' -a -e '/usr/bin/${executable}' -a "`readlink '/usr/bin/${executable}'`" != '/etc/alternatives/${executable}' ]; then rm -f '/usr/bin/${executable}' fi update-alternatives --install '/usr/bin/${executable}' '${executable}' '/opt/${sanitizedProductName}/${executable}' 100 || ln -sf '/opt/${sanitizedProductName}/${executable}' '/usr/bin/${executable}' else ln -sf '/opt/${sanitizedProductName}/${executable}' '/usr/bin/${executable}' fi # Always set the chrome-sandbox SUID bit so its sandbox works as a fallback. # # The upstream electron-builder template gates this on a `unshare --user true` # probe and only sets 4755 when unprivileged user namespaces look unavailable. # But this post-install script runs as root under dpkg/rpm, and root can create # a user namespace even when unprivileged userns is restricted (e.g. Ubuntu 23.10+ # with kernel.apparmor_restrict_unprivileged_userns=1). The probe therefore always # passes at install time and leaves chrome-sandbox at 0755, so on machines where # the app itself cannot use the userns sandbox Chromium aborts with: # "The SUID sandbox helper binary was found, but is not configured correctly ... # must be owned by root and have mode 4755". # # Setting 4755 unconditionally is the historical electron/chrome default and is a # safe fallback: on hosts where the bundled AppArmor profile grants userns, Chromium # still prefers the namespace sandbox; elsewhere the SUID sandbox keeps the app # launchable. See https://github.com/binaricat/Netcatty/issues/2607. chmod 4755 '/opt/${sanitizedProductName}/chrome-sandbox' || true if hash update-mime-database 2>/dev/null; then update-mime-database /usr/share/mime || true fi if hash update-desktop-database 2>/dev/null; then update-desktop-database /usr/share/applications || true fi # FPM packages copy icons directly and bypass distro hooks (e.g. Arch pacman # alpm hooks) that normally refresh the hicolor cache. Without this, KDE and # other icon themes cannot resolve Icon=${executable} and show a generic icon. if hash gtk-update-icon-cache 2>/dev/null; then gtk-update-icon-cache -q -t -f /usr/share/icons/hicolor || true fi # Install apparmor profile. (Ubuntu 24+) # First check if the version of AppArmor running on the device supports our profile. # This is in order to keep backwards compatibility with Ubuntu 22.04 which does not support abi/4.0. # In that case, we just skip installing the profile since the app runs fine without it on 22.04. # # Those apparmor_parser flags are akin to performing a dry run of loading a profile. # https://wiki.debian.org/AppArmor/HowToUse#Dumping_profiles # # Unfortunately, at the moment AppArmor doesn't have a good story for backwards compatibility. # https://askubuntu.com/questions/1517272/writing-a-backwards-compatible-apparmor-profile if apparmor_status --enabled > /dev/null 2>&1; then APPARMOR_PROFILE_SOURCE='/opt/${sanitizedProductName}/resources/apparmor-profile' APPARMOR_PROFILE_TARGET='/etc/apparmor.d/${executable}' if apparmor_parser --skip-kernel-load --debug "$APPARMOR_PROFILE_SOURCE" > /dev/null 2>&1; then cp -f "$APPARMOR_PROFILE_SOURCE" "$APPARMOR_PROFILE_TARGET" # Updating the current AppArmor profile is not possible and probably not meaningful in a chroot'ed environment. # Use cases are for example environments where images for clients are maintained. # There, AppArmor might correctly be installed, but live updating makes no sense. if ! { [ -x '/usr/bin/ischroot' ] && /usr/bin/ischroot; } && hash apparmor_parser 2>/dev/null; then # Extra flags taken from dh_apparmor: # > By using '-W -T' we ensure that any abstraction updates are also pulled in. # https://wiki.debian.org/AppArmor/Contribute/FirstTimeProfileImport apparmor_parser --replace --write-cache --skip-read-cache "$APPARMOR_PROFILE_TARGET" fi else echo "Skipping the installation of the AppArmor profile as this version of AppArmor does not seem to support the bundled profile" fi fi