Pack Install Doesn't Honor System user, running as root

If you attempt to perform a pack install from a git repo it uses root ssh keys.

From docs:

For SSH (URLs starting with git@) auth you have to create a deploy key, and require the system user running the command (stanley or root, depending on your configuration) to have a private key. Deploy keys are more secure than personal access tokens and can be configured on the per-repo basis.

However since we clone from python action and python action is shelled out as root and not system user this action will always use the root keys.

[mickmcgrath13]

Adding a specific identity file to the global ssh_config for our restricted domain works, too.

Add

Host github.restricteddomain.com
        IdentityFile /path/to/id_rsa

to /etc/ssh/ssh_config

(rhel7)

[cognifloyd]

The reason pack install runs as root, is because all actions run as root, because actionrunner runs as root.

So, actionrunner runs as root because of https://github.com/StackStorm/st2-packages/pull/195 and https://github.com/StackStorm/st2-packages/pull/205

I am specifically not happy about adding a user that has passwordless sudo privileges as part of packaging.

I think you are right, agreed. Thus I will revert actionrunner to run as root and corresponding changes … unless you have any other suggestions how to use actionrunner as unprivileged user. Since I see no options, actionrunner HAS TO BE ROOT at the moment.

Of course, then the various install methods (one liner and ansible at least) add stanley with passwordless sudo (skippable with some ansible vars). And then, we get all sorts of side effects of running as root instead of another user.

Now I’m seeing root owned files all over the place as my actions edit or modify files. A file owned by root has many potential actors (any service running as root). But stanley is a stackstorm user, so looking at StackStorm’s history is a good way to see why something may have been edited versus reviewing other logs first to see if it was some other service. It may not be more secure to run as stanley, but it is slightly more auditable.

Especially problematic is when an action edits a file that happens to be on our NFS v3 NAS. See, all users have the same access to the NAS as a system mounted drive except root who has special NFS permissions. All other users get mapped to a single NAS user, but root is root. So suddenly, files that are supposed to be world readable/writable are suddenly locked and only root can edit them. It can take a bit to reset those permissions so that they are again accessible correctly over both NFS (and to complicate it even further, through CIFS).

And then, there’s all of the sshconfig that I have to add to the root user. Yes, there’s passwordless sudo on that special system user, but I would rather not attach all of that config to the root user.

So, maybe actionrunner can continue running as root, but it should drop into a user (configured in st2.conf) to actually run the actions. That user could default to stanley. Or there needs to be a documented/supported way to configure actionrunner to run as stanley. The PR I found is from 2016, there might be other newer reasons (that I’m unware of) that actionrunner needs to run as root. I don’t know if there is anything else that will break if I, for example, drop in a systemd unit conf file that overrides the user for the actionrunner service.

In sum, I have two conflicting suggestions to fix this:

1. Make actionrunner run users as a non-root user by default (like stanley), but keep running actionrunner as root.
2. Document/support a method for configuring actionrunner to run as a non-root user instead of the default of root.