No current user owned ${XDG_CONFIG_HOME} (aka ${HOME}/.config) directory

[alepauly]

As originally reported by @ivailop in https://github.com/microsoft/azure-pipelines-image-generation/issues/1271:

Describe the bug
The hosted "Ubuntu 16.04" image has no current user owned ${XDG_CONFIG_HOME} (aka ${HOME}/.config) directory.

Expected behavior
Have existing ${XDG_CONFIG_HOME} (aka ${HOME}/.config) pre-created with current user (i.e. vsts) being the owner of it.

Actual behavior
${XDG_CONFIG_HOME} (aka ${HOME}/.config) directory does not exist. As being a de-facto location for storing user-specific configuration, installing dependencies using sudo would automatically create it with root being the owner of it. Subsequent non-sudo access to it would fail with Permission denied.

To reproduce:

- script: |
    ls -lsa ~/.config # -> ls: cannot access '/home/vsts/.config': No such file or directory
    sudo npm install -g eslint
    ls -lsa ~/.config # -> ls: cannot open directory '/home/vsts/.config': Permission denied

Image impacted
Ubuntu 16.04

[miketimofeev]

@ivailop could you please clarify why this directory should be owned for the current user for your builds?
Is it possible to add mkdir ~/.config as the first step of your build? I'm asking because the default user is created not during the image generation step but on some later VM provisioning step and adding this directory globally might be quite complicated.

[ivailop]

could you please clarify why this directory should be owned for the current user for your builds?

It must be owned by the current user as being in its HOME directory.
Normally, system dependencies (using sudo) are installed in the very beginning of a workflow. And as shown above that could lead to ~/.config being stolen (root owned, instead of user).

Later on, any tool being run (non-sudo) that needs to write access to ~/.config is being denied such!

Is it possible to add mkdir ~/.config as the first step of your build?

Yes, this is what I end up doing as a workaround. But it would be nice if someone does not have to discover a non-obvious problem like that and search for workarounds to fix it.

[miketimofeev]

@ivailop thanks for the answers. Does it make sense to pre-create configstore directory(under ~/.config) with the same permissions as well?

[ivailop]

@miketimofeev, I provided sudo npm install as a an example to demonstrate the problem with ~/.config only. I guess, it would not hurt having a pre-created configstore directory (under ~/.config) with the same/user permissions.
However, other tools (needing their own sub-directories) may exhibit the same problem? Do you think it is appropriate to look at them individually?

[miketimofeev]

@ivailop actually, it's the very first time we hear about such issues. Looks like for the most of the customers the permissions are fine

[miketimofeev]

@ivailop Pr has been merged. Waiting for vm rollout

[miketimofeev]

@ivailop the images have been deployed. Could you check the behavior, please?

[ivailop]

@miketimofeev, I might be interpreting it wrongly, but I read in #4 that you are planing to revert this change?

Before rushing should you consider the following:

• npm install requires to be run with sudo (beside my example here, there is also Npm i -g without sudo #599 discussing the case)
• sudo npm install steals ~/.config (as explains here) and makes it inaccessible for other subsequently non-sudo-run tools
• if having $XDG_CONFIG_HOME changes behavior for other tools (like nvm, mentioned in Update/Add nvm #4) then it might be better not to have it defined

However, in all cases just having ~/.config pre-created and user owned would not be breaking anyone. That way tools that exclusive relay on ~/.config (as a default for $XDG_CONFIG_HOME) would work as expected (not depending on any previously executed sudo-utility, e.g npm)

[miketimofeev]

@ivailop we've decided to get rid of the $XDG_CONFIG_HOME env variable, but left $HOME/.config pre-created and user-owned, that should be fine for everyone. By the way, do you have a chance to check the directory?

[ivailop]

By the way, do you have a chance to check the directory?

Yes, I checked it and it works fine now.

[miketimofeev]

Thanks for the confirmation. Closing the issue, but feel free to reopen if you have any concerns.