Simplify upgrade flow

[vpetersson]

One pain point for a fair amount of users is the upgrade process. It would be desirable to be able to run the upgrade from within the user interface.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[vpetersson]

Overview

The goal of this task is to be able to upgrade Screenly OSE from within the user interface. However, it quickly get complicated when we factor in the security elements. Hence, this overlaps with #876.

Requirements

• The goal is that both viewer and server shall run as a non-privilegued (and without ability to run sudo for arbitrary commands). We should assume this for the sake of the upgrade process.
• Since the upgrade will require root to run, we need to somehow run this process through another runner.
• The process runner should only be able to run whitelisted commands (and not arbitrary commands)
• The process runner should be owned by root.
• The system should be compatible with both a dockerized system and a non-dockerized system.
  • We can ignore a resin/balena-environment, since the upgrades are handled differently there.
• It should be possible to launch the upgrade from within the user interface and see the progress (as well as potential errors).

Possible solution

• We implement a task runner with Celary as described in #876. This task runner needs to run directly on the host system through systemd (even in the case of a dockerized environment because of the sudo solution below)
• We alter /etc/sudoers such that the user pi requires password to run arbitrary commands.
  • Note: This will also require us to run tvservice and similar through this mechanism.
• We create a new script called /usr/local/sbin/upgrade-screenly.sh, which is a hard coded script that only runs the installer. This file should have the permission 0700 and owned by root to improve security.
  • It is essential that this script does not simply call on a script in ~/screenly that is owned by pi, as that would allow an attacker to execute any command as root.
  • We should also probably fetch this script directly from Github from the master branch instead of copied from the ~/screenly folder to improve security further.
• We add a rule to /etc/sudoers that allows the user pi to run /usr/local/sbin/upgrade-screenly.sh without a password.
• With all those pieces in place, we can now create a Celary task that calls on upgrade-screenly.sh through sudo, which in turn executes the upgrade script.

[vpetersson]

@sublimino - I'm actually really curious about your feedback here.

[rusko124]

This issue was solved in Celery branch(PR https://github.com/Screenly/screenly-ose/pull/987). The subsequent discussion, I recommend to move here #1081

@vpetersson I think we can close this.