bug: ASDF fails to load in some sudo/su contexts

[mcandre]

Describe the Bug

Hi,

While provisioning Ruby environments upon enterprise Jenkins agents, I noticed a hidden assumption within ASDF that causes the ASDF bash load process to fail.

Note two workarounds:

• Jenkins pipelines probably still work, due to connecting directly to the Jenkins SSH account using known credentials, as opposed to sudo/su. But that breaks SSH troubleshooting from individual engineer accounts.
• The user can override a default bash shell to target sh, then run sudo/su, then explicitly cd to the Jenkins home directory, and finally launch bash to load ASDF. But that's tedious.

Steps to Reproduce

1. chmod 0700 ~ in your normal Unix account.
2. Create a Jenkins Unix account.
3. Install ASDF in the Jenkins account.
4. Use sudo or su to change context to the Jenkins account.

Expected Behaviour

ASDF is available and working.

Actual Behaviour

The ASDF source line in the Jenkins account's .bashrc file terminates too early, citing cd permission errors.

The asdf command fails to register. asdf version reports that no such command is found.

Environment

Redacted

asdf plugins affected (if relevant)

No response

[skull-squadron]

Asdf isn't the problem. The problem is a failure to start a clean login shell as the target user, and so the environment is inherited and wrong.

/usr/bin/env sudo -iu jenkins -- ...

[mcandre]

I suspect asdf is triggering a dirty login shell as a consequence of asdf's assumptions about the authorization to cd into arbitrary /home/* directories, which is not true in all environments.

[Stratus3D]

I think this issue has been fixed by the Go rewrite (PR #1805). Would you want to test out a dev build of the new Go code? (https://github.com/asdf-vm/asdf/releases/tag/54d15e3)

[Stratus3D]

Closing as I believe this has been fixed by the Go rewrite.