fix: localstack installation on ubuntu/i3

[carole-lavillonniere]

This PR fixes two installation issues with the LocalStack CLI:

1. Global installation on Linux without desktop environment (using i3 in my case): When pkexec fails due to missing polkit agent (graphical authentication dialog), the installer now falls back to prompting for sudo password via VS Code input box
2. Local installation PATH availability: The LocalStack CLI binary path is now immediately added to the current VS Code process environment, eliminating the need to restart VS Code after installation

This is the password prompt when using i3 (using vscode):

This is the password prompt when using Gnome desktop env (using pkexec):

Sorry for the literal screen shot 😁

[tiurin]

Thanks for addressing this! 👏

I think it's not the best security practice to ask for system credentials in the VS Code input box. A malicious extension could easily mimic such input box. However, I think the implementation is acceptable as long as:

• it stays only as a fallback for advanced Linux users who use custom setups and are more likely to understand the risks/find a workaround to install LocalStack in a different way.
• password variable scope is kept as the smallest possible so that the password string is garbage-collected as soon as possible.
• stdin approach is kept
• no storage/caching - every command should ask for password again.

suggestion: add these points and risks as comments, this code path should be as guarded as possible from misuse.

[tiurin]

praise: nice way to avoid exposing password in any kind of output! 👍

[carole-lavillonniere]

Thanks for addressing this! 👏

I think it's not the best security practice to ask for system credentials in the VS Code input box. A malicious extension could easily mimic such input box. However, I think the implementation is acceptable as long as:

* it stays only as a fallback for advanced Linux users who use custom setups and are more likely to understand the risks/find a workaround to install LocalStack in a different way.

* `password` variable scope is kept as the smallest possible so that the password string is garbage-collected as soon as possible.

* `stdin` approach is kept

* no storage/caching - every command should ask for password again.

suggestion: add these points and risks as comments, this code path should be as guarded as possible from misuse.

Totally agree. I decided to go with this because it seemed the only alternative was to let the install fail on such systems. Added a comment explaining the security concern like you suggested.