Open johncrim opened 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).
@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.
@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
Resolve issues with loading the module when the user does not have access to the .Azure directory
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.
@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.
@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.
@wyunchi-ms, could you follow this issue?
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.
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.
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. But
OnImportis used by all the cmdlets in
AzAccount` 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.@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 ?
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?
@wyunchi-ms Is the issue fixed ? Please let us know once the issue is fixed.
is there any solution , im facing the same issue on a powershell docker container
@wyunchi-ms Is the issue fixed ?
Description
Installing the Az module on Linux within
sudo
(to complete a global install) creates an~user/.Azure
directory 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.ps1
script 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/.Azure
directory 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/.Azure
after the install.