Open johncrim opened 5 years ago
markcowl
commented
5 years ago Module installation wouldn't cause this to happen, but module loading might, as there are some checks of the .Azure folder in the psm1 script for the module (so likely, this occurs in Get-Command Uninstall-AzureRm).
johncrim
commented
5 years ago @markcowl - that makes sense. I suppose I could skip the Uninstall-AzureRm command, but it seems to be recommended to remove AzureRm if using Az.
markcowl
commented
5 years ago @johncrim yeah, but you shouldn't have AzureRM in linux in any case. either that, or change the permissions on the directory.
There are two ways I can think of for us to fix this, both of which we should do,
1- Update the module load script to not create this folder if it doesn't exist 2- Update our context load to print a warning when this error occurs and default to session-based auth
markcowl
commented
5 years ago Resolve issues with loading the module when the user does not have access to the .Azure directory
SplitThePotCyrus
commented
5 years ago We are experiencing similar issue, however we did not issue any Uninstall-AzureRm command and still got the ~/.Azure directory just by doing Install-Module Az -Force -AllowClobber
The solution that @johncrim provided did not solve our issue.
After tampering with _work/_tasks/AzurePowerShell_72a1931b-effb-4d2e-8fd8-f8472a07cb62/4.0.7/InitializeAz.ps1 we found out that our $endpointObject.authenticationType == null, but $endpointObject.applicationTokenCredentials.authType == "spnKey" so we modified as stated below for now until this is fixed in the lib.
if ($endpointObject.scheme -eq 'ServicePrincipal') {
try {
if ($endpointObject.authenticationType -ieq 'SPNKey' -Or $endpointObject.applicationTokenCredentials.authType -ieq 'spnKey') {
$psCredential = New-Object System.Management.Automation.PSCredential($endpointObject.servicePrincipalClientID, (ConvertTo-SecureString $endpointObject.servicePrincipalKey -AsPlainText -Force))
Write-Host "##[command]Connect-AzAccount -ServicePrincipal -Tenant $($endpointObject.tenantId) -Credential $psCredential -Environment $environmentName"
...let me know ff there is any information or detail I can provide to help the team figure this out.
EDIT:
Of course, directly after writing this, karma bit me as now there was a new version of the task on path _work/_tasks/AzurePowerShell_72a1931b-effb-4d2e-8fd8-f8472a07cb62/4.0.8/InitializeAz.ps1, which meant I have to reapply the fix to keep the pipeline moving 😸
EDIT2: As it turns out, our main issue was due to an old "Service Connection" from Azure DevOps to Azure Cloud. Updating the service connection solved our issue. But the fact remains that ~/.Azure folder gets created by just installing the Az module. Not that it bothers us at the moment.
markcowl
commented
5 years ago @SplitThePotCyrus So, I think you are referring to ADO installtion, instead of Install-Module installation. I still think in this case the root cause is the same.
johncrim
commented
5 years ago @markcowl : Apologies for the super-tardy reply on this:
@johncrim yeah, but you shouldn't have AzureRM in linux in any case. either that, or change the permissions on the directory.
AzureRM is (or was, when I created this issue) installed on the Azure DevOps Ubuntu 16.04 agent image. The only way to use Az commands in builds/deploys was to install it from bash.
I think the key fix that I'm looking for is that this directory should not be created within a non-root user's home directory, while running as root. If a directory is created for the root user's session info, and file permissions are limited to root user access only, it should be /home/root/.Azure, not /home/(other user)/.Azure.
erich-wang
commented
5 years ago @wyunchi-ms, could you follow this issue?
wyunchi-ms
commented
5 years ago Hi @johncrim.
We didn't recurrence your problem on both ubuntu 16.04, ubuntu 18.04 and wsl. Are you use sudo instead of login as root? When you are using sudo, you are still the user who login so the home directory will not be /root or /home/root. But the permission of dir will be root. I'm not sure whether this can solve your problem.
johncrim
commented
5 years ago Yes, I'm using sudo. The bug I'm reporting is using sudo, not su - see the issue title.
This is a build script (running in an Azure devops agent). Using sudo is a standard use-case, b/c it's a bad practice to give everyone the root password. In this case I technically could login as root using sudo su -, but I shouldn't have to add that level of indirection to not leave the user directory in a bad state, and the Azure module unusable.
Again, the directory should not be created as root-owned, in a non-root user directory. That's the nasty side-effect that should not occur when the module is installed.
I reported this to save other users, and Microsoft support people, the hassle of figuring it out. This is basic "how things should work on Linux" behavior.
wyunchi-ms
commented
4 years ago Hi @johncrim we will try to fix this issue. The cause of this issue is that the method OnImport which will be invoked when cmdlet is imported will check the .Azure folder and create it if it's not exist. There are two ways to fix this.
` set. This is the most reasonable way. ButOnImportis used by all the cmdlets inAzAccount` module this will affect a lot of cmdlets and will cost many time to refact the code.Uninstall-AzureRm follow another OnImport method which will not create .Azure folder. This will cost less but a little ugly.
We will discus this in the meeting.
20shivangi
commented
4 years ago @wyunchi-ms We are still facing this issue, even on MAC machine in hosted agent : https://github.com/microsoft/azure-pipelines-tasks/issues/12030
Can you provide some ETA when this will be fixed ?
wyunchi-ms
commented
4 years ago Hi @20shivangi , we will try to fix this. Before we fix this issue, can you use the workaround to pass this first? The workaround is to delete the directory /{username}/.Azure whoes owner is root or create /{username}/.Azure with current user permission at the beginning of pipeline?
20shivangi
commented
4 years ago @wyunchi-ms Is the issue fixed ? Please let us know once the issue is fixed.
darkweb-123
commented
4 years ago is there any solution , im facing the same issue on a powershell docker container
daveneeley
commented
4 years ago 20shivangi
commented
4 years ago @wyunchi-ms Is the issue fixed ?
Description
Installing the Az module on Linux within
sudo(to complete a global install) creates an~user/.Azuredirectory owned byroot. Subsequently the user account cannot access files in the directory, causing errors connecting to Azure.This problem did not exist before 4/8. I suspect that a new version of Az was released on 4/8, causing this regression.
I have provided complete details on my problem, with repro steps, here: https://developercommunity.visualstudio.com/content/problem/523218/azure-powershell-script-new-error-there-was-an-err.html
Steps to reproduce
This bug originally bit me while installing Az on an Ubuntu 16.04 build agent in Azure DevOps, though I would expect this issue to affect all Linux users.
To install Az on an Ubuntu 16.04 build agent, I use the bash command:
The
build/install-az-modules.ps1script is:After running this script (again, within sudo - I'm not aware of a better way to install Az globally, and remove AzureRm globally), the following command fails:
Environment data
Module versions
Debug output
Workaround
The workaround is to delete the
~user/.Azuredirectory after installing the Az module, eg:After doing this, the directory is properly recreated after running Az commands as user.
However, it's still a bug (and a new bug) that root owns
~user/.Azureafter the install.