sudo pwsh
PowerShell 7.1.4
https://aka.ms/powershell
Type 'help' to get help.
PS /home/user> Connect-AzAccount
DEBUG: Sought all Az modules and got latest version 6.3.0
DEBUG: 2:53:28 PM - ConnectAzureRmAccountCommand begin processing with ParameterSet 'UserWithSubscriptionId'.
DEBUG: 2:53:28 PM - Autosave setting from startup session: 'CurrentUser'
DEBUG: 2:53:28 PM - No autosave setting detected in environment variable 'AzContextAutoSave'.
DEBUG: 2:53:28 PM - Using Autosave scope 'CurrentUser'
Then the whole process is blocked.
Expected behavior
Pop up a website to login account or tell the reason why can't pop up.
Actual behavior
The whole process is blocked. PowerShell hangs with high CPU load. No popup is shown.
Possible solution
User installed browser as nonroot app. So when user used an elevated pwsh to call browser, this behavior is not allowed in this case. But MSAL didn't catch this case. A pre-detection should be done or the error should be thrown out.
Additional context / logs / screenshots
Add any other context about the problem here, such as logs and screenshots.
Run another pop-up command provided this error: Running Firefox as root in a regular user's session is not supported.
$ sudo pwsh
[sudo] password for user:
PowerShell 7.1.4
https://aka.ms/powershell
Type 'help' to get help.
PS /home/user> Import-Module Az
PS /home/user> Send-Feedback
Want to provide feedback about Azure PowerShell? Take a quick survey and let us know how we are doing: https://aka.ms/azpssurvey?Q_CHL=FEEDBACK. Do you want to open the link? (Y/N)
Running Firefox as root in a regular user's session is not supported. ($XAUTHORITY is /run/user/1000/gdm/Xauthority which is owned by user.)
Running Firefox as root in a regular user's session is not supported. ($XAUTHORITY is /run/user/1000/gdm/Xauthority which is owned by user.)
Running Firefox as root in a regular user's session is not supported. ($XAUTHORITY is /run/user/1000/gdm/Xauthority which is owned by user.)
/usr/bin/xdg-open: 869: iceweasel: not found
/usr/bin/xdg-open: 869: seamonkey: not found
/usr/bin/xdg-open: 869: mozilla: not found
/usr/bin/xdg-open: 869: epiphany: not found
/usr/bin/xdg-open: 869: konqueror: not found
/usr/bin/xdg-open: 869: chromium: not found
/usr/bin/xdg-open: 869: chromium-browser: not found
/usr/bin/xdg-open: 869: google-chrome: not found
/usr/bin/xdg-open: 869: www-browser: not found
/usr/bin/xdg-open: 869: links2: not found
/usr/bin/xdg-open: 869: elinks: not found
/usr/bin/xdg-open: 869: links: not found
/usr/bin/xdg-open: 869: lynx: not found
/usr/bin/xdg-open: 869: w3m: not found
xdg-open: no method available for opening 'https://aka.ms/azpssurvey?Q_CHL=FEEDBACK'
PS /home/user>
So what is happening here is that MSAL uses a tool called "xdg-open" to find and launch the browser. This is the standard approach for launching browser on Linux.
According to https://ss64.com/bash/xdg-open.html we should not call xdg-open with root. But since the user starts from root, the login command is called with root, it in turns invokes MSAL from root, who in turns does a Process.Start("xdg-open", "auth_url"), hence running xdg-open as root.
To handle this, we should kick off xdg-open as the non-root user, equivalent to su $SUDO_USER -c "xdg-open https://example.com":
Read the SUDO_USER env variable
If set, we're being called from SUDO
When invoking xdg-open, add ProcessStartInfo::UserName = Environment.Read("SUDO_USER")
@BethanyZhou - the top level method AcquireTokenInteractive.ExecuteAsync(CancellationToken) allows you to pass a cancellation token, which you can use to cancel this operation (manually or via timeout).
We do not recommend setting a timeout because authentication can take a long time, for example if the user has to perform MFA or if the user is prompted to change their password.
Instead, we recommend that you allow the user to cancel the operation. In a UI app, you can show a cancel button. In a CLI app, you can ask the user to press a key combo like CTRL-C or smth to stop waiting. I guess they can already press a key combo to cancel the current running script...
@BethanyZhou installed Az module using the following command on Mac:
Install-Module -Name Az -Scope CurrentUser -Repository PSGallery -Force
And ran Az-Connect. It ran well. The powershell version is 7.1.5 and this is Mac (not Ubuntu). Do you face the problem only on Ubuntu or also on Mac?
Here is the possible solution discussed today:
Prior to execution check the conditions and then conditionally launch the dialog.
Instead of waiting for the response using polling mechanisms that consumes CPU, launch a socket and wait for the response. There should also be a timeout in this.
The priority is to reduce the CPU usage and allow timeouts.
@SameerK-MSFT - not sure I understand why the priority is to reduce CPU usage? This seems like a functional issue to me:
When running as sudo, the system browser doesn't start.
The fact that CPU usage is high is a side effect that should go away if we fix the bug.
My suggestion for fixing the bug is to detect if running as SUDO and to invoke xdg-open as non-sudo in this case. To do this, you can:
Read the SUDO_USER env variable. If set, we're being called from SUDO
When invoking xdg-open, add ProcessStartInfo::UserName = Environment.Read("SUDO_USER")
Was this attempted? Have a look at StartDefaultOsBrowserAsync from NetCorePlatformProxy
Note that we do not use polling, we use a listening mechanism and cancellation is indeed supported. Timeouts in .NET are implemented via cancellation.
