Running a command as another user from a script: sudo -u, runuser, su -c, and PowerShell's -Credential

Goal

Run a specific command as a different account from within a script, choosing the right tool for whether a password is available, whether a login environment is wanted, and whether the target is local or remote.

Prerequisites

sudoers entries or group membership granting the needed privilege on Linux; on Windows, a credential the calling context is allowed to use non-interactively.

Steps

1. sudo -u <user> <command> runs <command> as <user> under the sudoers policy, using the caller's own credentials rather than the target's; both runuser(1) and su(1) are described identically in their manual pages as tools to "run a command with substitute user and group ID", but differ: su prompts for the target account's own password (no prompt when the caller is root), while runuser works only when run as root and never prompts.
2. sudo -i runs the target user's login shell, as sudo(8) describes it, reading that account's profile files and starting in its home directory. Plain sudo -u user command runs no login shell, but with the default env_reset it still passes only a minimal environment, and where sudoers sets secure_path (most distributions) PATH is replaced, so call commands by absolute path.
3. sudo -E (--preserve-env) asks the security policy to let the caller's existing environment variables through instead of resetting them, described in sudo(8) as letting the user "preserve their existing environment"; sudo refuses it when the policy does not allow it, secure_path still overrides PATH, and dangerous variables such as LD_PRELOAD are always stripped. Prefer --preserve-env=VAR1,VAR2 and verify with sudo -E env | grep <VAR>.
4. runuser -u appuser -- /opt/app/bin/migrate.sh --flag executes the command directly, without a shell. su -c 'command' appuser (and runuser -l appuser -c ...) hands one string to the target account's shell, so pass it as a single quoted argument, never splice untrusted data into it, and add -s /bin/sh for service accounts whose shell is nologin.
5. On Windows, build a credential object without putting the password on the command line: $cred = Get-Credential interactively, or for unattended use a PSCredential from a secret store (Get-Secret, or a DPAPI-protected file read with ConvertTo-SecureString), never a literal string in the script. Then Start-Process -FilePath ... -Credential $cred -Wait runs the process as that user. It cannot be combined with -Verb RunAs (separate parameter sets), so it does not elevate, and inside a WinRM remoting session it commonly fails with access denied; there, use Invoke-Command -Credential instead.
6. For remote execution, New-PSSession -ComputerName <host> -Credential $cred (or Invoke-Command -ComputerName ... -Credential $cred) authenticates the remote session as that account.
7. Verify the effective identity after the switch (id on Linux; whoami or $env:USERNAME in the new PowerShell context) rather than assuming the elevation call succeeded silently.

Expected result

The intended command runs under the intended account's identity and environment; the calling script's own log shows which account each step ran as, and no plaintext password appears in process listings, shell history or logs.

Limits and test basis

sudo's behaviour (whether -E is honoured, whether a password is required at all) is entirely controlled by the local sudoers policy, not by the flags alone. Get-Credential is interactive by design; unattended scripts need a pre-provisioned secret store.