Always inform user when sudo is required

[acburdine]

Because of the nature of some of the setups (systemd, nginx configuration), sometimes a sudo-level command must be run by the CLI. To be as transparent and clear (e.g. not confusing) as possible, any CLI action that requires sudo access should first log and inform the user as to what is being done.

If verbose output is not turned on, just a basic description should be logged, e.g. "Systemd configuration is being moved into place, you may be prompted for your password". However, if verbose logging is enabled, the actual command should be logged as well.

[cjsheets]

I'm glad to see this issue raised. I was trying out CLI (awesome tool btw) on a staging server and was a bit surprised by sudo (+ the lack of information relating to what it was doing).

In addition to the considerations you mentioned, would it also be possible to document the likely commands that require elevated privileges elsewhere (like developer docs)?

Typically, I'd run ghost-cli with a user that has no sudo access. If sudo is required for basic cli functions it would be nice to at least lock it to a set of available commands (ex. sudo mv someFilename /lib/systemd/system) even if the docs aren't exact and require some reasoning by the admin.

[PaszaVonPomiot]

@acburdine if you list all the sudo commands that ghost user needs to use I will create a sudo profile fit for that purpose.

[PaszaVonPomiot]

I have tested the sudo requirements for a little bit and it appears that following sudoers commands will be sufficient for ghost user (this is on Centos 7):

ghost   ALL=(root)      NOPASSWD: /bin/systemctl start ghost*, \
                                  /bin/systemctl stop ghost*, \
                                  /bin/mv ghost_*.service /lib/systemd/system, \
                                  /bin/rm /lib/systemd/system/ghost*

Please bear in mind that above sudoers setup is not considered safe due to wildcards.
I see two solutions to have safe persmissions for ghost-cli - one is to take above sudoers and add all the exceptios for wildcards (eg. !/bin/systemctl stop ghost* *) which is a bit messy. Second is to have a script owned by root that will be used by ghost user via sudo. This way single line would be enough in /etc/sudoers file. Example file could be /usr/local/bin/ghost/ghost_cli.sh which would be used by Ghost-CLI with sudo.
So for example you would type ghost start and ghost-cli would do sudo /usr/local/bin/ghost/ghost_cli.sh start.
I'm not sure if that's the most elegant solution but that's certainly a possibility.

[acburdine]

@PaszaVonPomiot thanks for that list! One of the things that we've planned to do before releasing Ghost-CLI 1.0 is the creation of a user account specifically for Ghost itself during setup (similar to what MySQL does). The idea is that you'll run ghost-cli commands as root/a full sudo user, and the Ghost process itself will be run as a specific (non-sudo, possibly rooted) user.

[PaszaVonPomiot]

@acburdine yes I've seen the plan for ghost-cli 1.0. I fully agree with ghost-cli creating system user and database user with permissions fit for purpose. The sysytem user account would need to perform systemctl start/stop ghost_*.service command. Can we achieve that without sudo?

[acburdine]

Yup, actually we did figure out a solution to work around the need for sudo in the ghost user 😄. The only thing it would need it for is auto/1-click-updates, which (at the moment), won't happen until sometime after ghost 1.0. However, one of the things that goes in the systemd configuration is a auto-restart directive, which means that on auto or 1-click updates, Ghost can just kill itself once all of the new stuff has been downloaded, and rely on systemd to restart the process, which will then pick up the new updates.