ghost exec/ghost repair-permissions commands

[acburdine]

Supersedes #311 , related to #307

In order to facilitate management of an installed Ghost instance with as little pain as possible, while still not messing up file/folder permissions, two new commands needed to be added to the CLI via the linux extension:

• ghost exec <cmd>

ghost exec <cmd> will essentially work similar to sudo <cmd> but after the sudo command is run, all permissions will be repaired so that Ghost itself isn't affected.

• ghost repair-permissions

ghost repair-permissions will go through the files in the ghost install directory, ensuring that all file permissions are correct

Later:

• add permissions checks into a ghost doctor check

[acburdine]

Related: ghost run runs Ghost in the foreground, and is useful for debugging why a Ghost instance is not starting. Because of the permissions changes around the linux user spec - we also need to add some modifications to the ghost run command.

Reasoning:

• ghost run runs in the foreground, meaning any files created during the process are going to be run as the user that actually runs the process. Example, I have an acburdine user and I run ghost run as that user, any files created will be owned by acburdine. This creates problems for the linux user extension for two reasons:
  • the content/logs folder will by owned by ghost, so any attempt to write to that directory as another user (e.g. acburdine) will fail with write permissions errors
  • if the user runs sudo ghost run, it will not run into the same issue, but then any log files will be owned by root, meaning if you tried to run ghost normally again (e.g. with ghost start and systemd), you would get other permissions errors because the ghost linux user wouldn't be able to write to the log file. This is the reason why the error in Ghost log file permissions #303 occurred.

Solution:

• if the user is running on linux and the CLI has configured the ghost system user for the instance (e.g. switched the ownership of the content folder to the ghost user), then we always need to run ghost run as the ghost user so that we don't mess up file permissions.
• To accomplish this, the linux extension will first check if it's running on linux and the CLI has configured the ghost system user.
  • if either are false, the linux user won't do anything, meaning you can run ghost run normally without sudo
  • If both are true, and the user is not root (e.g. sudo), then it will error, because otherwise the CLI cannot correctly switch the user id of the process to be that of the ghost user.
  • if both are true and the user is root, then it will use process.setuid() and process.setgid(), to switch the process user and essentially run ghost run as the ghost user, thus preserving correct file permissions.

Note: PR implementation of this is in #327

[github-actions]

Our bot has automatically marked this issue as stale because there has not been any activity here in some time. The issue will be closed soon if there are no further updates, however we ask that you do not post comments to keep the issue open if you are not actively working on a PR. We keep the issue list minimal so we can keep focus on the most pressing issues. Closed issues can always be reopened if a new contributor is found. Thank you for understanding 🙂