Ansible: Windows 10/WSL: Ansible cannot read ansible.cfg from NTFS mounts

[AngellusMortis]

SUMMARY

Ansible 2.6.1 added https://github.com/ansible/ansible/pull/42070 which makes Ansible ignore ansible.cfg files in 777 directories. The problem is that all NTFS mounts (anything under /mnt/c) in WSL on Windows 10 are 777 because their permissions are managed by Windows.

Detecting a WSL install is pretty easy, I have been using ansible_kernel.find('Microsoft') != -1 to detect WSL. Tested on Arch, Ubuntu and Kali.

ISSUE TYPE

• Bug Report

COMPONENT NAME

lib/ansible/config/manager.py

ANSIBLE VERSION

ansible 2.6.1
  config file = None
  configured module search path = [u'/home/cbailey/.ansible/plugins/modules', u'/usr/share/ansible/plugins/modules']
  ansible python module location = /usr/local/lib/python2.7/dist-packages/ansible
  executable location = /usr/local/bin/ansible
  python version = 2.7.15 (default, May  1 2018, 05:55:50) [GCC 7.3.0]

CONFIGURATION

N/A

OS / ENVIRONMENT

Windows 10 + any WSL distro

STEPS TO REPRODUCE

1. Install a WSL distro
2. sudo pip install ansible==2.6.1
3. Put an ansible.cfg some where on your C:\ drive
4. cd to Directory from WSL
5. Run any Ansible command

EXPECTED RESULTS

ansible.cfg files on Windows mounts in WSL are not ignored

ACTUAL RESULTS

ansible.cfg file is ignored with the following warning:

[WARNING] Ansible is in a world writable directory (/mnt/c/**), ignoring it as an ansible.cfg source.

[ansibot]

Files identified in the description:

• lib/ansible/cli/config.py

If these files are inaccurate, please update the component name section of the description or use the !component bot command.

click here for bot help

[ansibot]

Files identified in the description:

• lib/ansible/config/manager.py

If these files are inaccurate, please update the component name section of the description or use the !component bot command.

click here for bot help

[abadger]

Detecting that the system is WSL would still leave a vulnerability. We'd have to detect that the file isn't world writable or in a world writable directory despite the permissions saying that it is.

We also don't support Ansible on Windows hosts so we can't guarantee a fix will be created for this.

[AngellusMortis]

I absolutely understand the need for security, but there should at least be an option some how to disable that. Maybe something that has to be in the /etc/ansible/ansible.cfg specifically or something similar that makes it harder to flip on.

There are other use cases where it would not just be a Windows 10 NTFS mount to WSL that this would occur. If you have an NTFS mount or an Azure File Share mount on a locked down Linux build box, the mount would be 777, but it does not mean it is insecure to trust files from that location.

OpenSSH does not stop you from enabling root password login, but it does tell you it is a bad idea. Most security guidelines are relative to what the purpose is and the context around it.

[zoredache]

Maybe you could allow people to whitelist directories from this check via an environment variable? Something like ANSIBLE_TRUSTED_CONFIGPATHS or something? If the config is inside a path in that variable, then skip the permissions check?

I am not that good at python, but maybe something like this?

diff --git a/lib/ansible/config/manager.py b/lib/ansible/config/manager.py
index 48cf2cba3a..b356c84b9e 100644
--- a/lib/ansible/config/manager.py
+++ b/lib/ansible/config/manager.py
@@ -146,6 +146,10 @@ def find_ini_config_file(warnings=None):
    ''' Load INI Config File order(first found is used): ENV, CWD, HOME, /etc/ansible '''
    # FIXME: eventually deprecate ini configs

+    trusted_paths = os.getenv("ANSIBLE_TRUSTED_CONFIGPATHS",None)
+    if isinstance(trusted_paths, string_types):
+        trusted_paths=list(filter(None,trusted_paths.split(':')))
+
    path0 = os.getenv("ANSIBLE_CONFIG", None)
    if path0 is not None:
        path0 = unfrackpath(path0, follow=False)
@@ -154,7 +158,9 @@ def find_ini_config_file(warnings=None):
    try:
        path1 = os.getcwd()
        perms1 = os.stat(path1)
-        if perms1.st_mode & stat.S_IWOTH:
+        if trusted_paths and [i for i in trusted_paths if path1.startswith(i)]:
+            path1 += "/ansible.cfg"
+        elif perms1.st_mode & stat.S_IWOTH:
            if warnings is not None:
                warnings.add("Ansible is in a world writable directory (%s), ignoring it as an ansible.cfg source." % to_text(path1))
            path1 = None

Then I can just set export ANSIBLE_TRUSTED_CONFIGPATHS=/mnt/c/Users/ in my shell profile?

[rbaradari]

You can set the ANSIBLE_CONFIG variable to point to your world writable ansible.cfg and it currently works.

[abadger]

Yep, it's only current working directory that we're making this test on.
It prevents surprises like exploring your file tree and then running
ansible in /tmp and picking up a malicious ansible.cfg

On Thu, Jul 5, 2018, 11:23 PM Ramin Baradari [e-mail]
wrote:

You can set the ANSIBLE_CONFIG variable to point to your world writable
ansible.cfg and it currently works.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/ansible/ansible/issues/42388#issuecomment-402938591,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAMxWr8Z2LerEPWWmwZu1BR5RT9qgdnTks5uDwJ5gaJpZM4VEmwB
.

[116davinder]

i am using vagrant on windows to run ansible playbooks.

Its still failing even after setting ansible_config value.

[root@controller ]# echo $ANSIBLE_CONFIG
/home/vagrant/projects/DevOps-Projects/

[root@controller mapr-ansible-paysafe]# ls -lh ansible.cfg
-rwxrwxrwx. 1 vagrant vagrant 73 Jul 9 07:43 ansible.cfg

[root@controller ]# ansible -m ping all -i environment/XXXX/cluster.ini -v
[WARNING] Ansible is in a world writable directory (/home/vagrant/projects/DevOps-Projects), ignoring it as an ansible.cfg source.
No config file found; using defaults

Temporary Solution
Install Only ansible 2.6.0

[agaffney]

The ANSIBLE_CONFIG env var should point to a file, not a directory.

[sebastian-marinescu]

I've stumbled upon the same issue, and I don't want a global cfg for all my projects, I need a project-relative configuration. So how can I fix this for me?

[AngellusMortis]

I've stumbled upon the same issue, and I don't want a global cfg for all my projects, I need a project-relative configuration. So how can I fix this for me?

pip install ansible==2.6.0 until the devs decide how they want to handle this.

[mrsombre]

Problems on Vagrant shared folder too, it is 0777 only mode for folders in this case and can't be changed.
Please, add check that CWD folder == folder containing playbook file, and then do not check for world writable. Or maybe try to find ansible.cfg in the same folder as playbook file? Would be helpful for vagrant on windows users.

[sgreiner]

I think I found a solution for 2.6.1 and so on...

Create this file in your wsl: /etc/wsl.conf

Content:

[automount]
enabled = true
mountFsTab = false
root = /mnt/
options = "metadata,umask=22,fmask=11"

[network]
generateHosts = true
generateResolvConf = true

After that all /mnt/c/foo will have different folder permissions (not 777 any more) and you will be able to use chmod.
It requires you to have the latest WSL as far as I know.
wsl.conf docs

[abadger]

Okay, the comment in https://github.com/ansible/ansible/issues/42388#issuecomment-403926971 is the equivalent of advice we'd tell people mounting an ntfs or vfat filesystem under Unix so I think that is the correct solution here.

For people using ANSIBLE_CONFIG (correctly... as agaffney notes, it needs to point to a file not a directory), please check whether the config file is actually being ignored or it's just spitting out an extra warning.

From looking at the code, I think that the config file is read when ANSIBLE_CONFIG is used correctly. If that happens to also be the current working directory, then the warning message is spit out in addition to the config being used because it is listed in ANSIBLE_CONFIG. If that is indeed the symptom being seen, it should be easy to fix it to only emit the warning if the only reason for the config to be used is because it's in the current working directory.

[bcoca]

```diff --git a/lib/ansible/config/manager.py b/lib/ansible/config/manager.py
index c308c3810d..36641d9e01 100644
--- a/lib/ansible/config/manager.py
+++ b/lib/ansible/config/manager.py
@@ -150,6 +150,8 @@ def find_ini_config_file(warnings=None):
''' Load INI Config File order(first found is used): ENV, CWD, HOME, /etc/ansible '''
# FIXME: eventually deprecate ini configs

• warn_cwd_public = False
  +
  path0 = os.getenv("ANSIBLE_CONFIG", None)
  if path0 is not None:
  path0 = unfrackpath(path0, follow=False)
  @@ -159,8 +161,7 @@ def find_ini_config_file(warnings=None):
  path1 = os.getcwd()
  perms1 = os.stat(path1)
  if perms1.st_mode & stat.S_IWOTH:
• if warnings is not None:
• warnings.add("Ansible is in a world writable directory (%s), ignoring it as an ansible.cfg source." % to_text(path1))

• warn_cwd_public = True
  path1 = None
  else:
  path1 += "/ansible.cfg"
  @@ -175,6 +176,8 @@ def find_ini_config_file(warnings=None):
  else:
  path = None

• if warn_cwd_public and warnings is not None and path != os.getcwd() + "/ansible.cfg":

• warnings.add("Ansible is in a world writable directory (%s), skipped from possible ansible.cfg sources list." % to_text(path1))
  return path```
  something like this should be more precise

[goettl79]

For me the best solution is to change the permission on an wsl mounted nfs filesystem with Metadata option turned on. To do that follow this procedure here: https://blogs.msdn.microsoft.com/commandline/2018/01/12/chmod-chown-wsl-improvements.

Basically do the following for your ntfs mount to enable "chmod":

sudo umount /mnt/c
sudo mount -t drvfs C:/mnt/c -o metadata

And then do the chmod on the folder and everything is fine again. After the metadata was attached to the folder it stays there. should be wsl default for my humble opinion.

[NL9]

Solution for Vagrant, edit Vagrantfile and add mount_options:

config.vm.synced_folder "../my-folder", "/home/vagrant/my-folder",  mount_options: ["dmode=775"]

[Petrox]

This is a nice example why ansible is a high upkeep module to build your project on.

I have prepared a vagrant+virtualbox+ansible project 3 years ago. Since then every 5 months ansible breaks. I have to implement workarounds to KEEP IT WORKING THE SAME WAY. So I can't tell the (few) users of the system that "this works", because every so often it just breaks. This was working 3 weeks ago, and it is not working now. And it's not a mayor version change, just a minor one, so breaking changes are not an option.

(see "touch" not implemented for years, apt module not having autoremove but has warnings implemented that I should not call "apt" as a command, stat.md5 removed without notice, vault_password.txt location was not allowed to set in ansible.cfg (feature request closed, then years later implemented) etc...)

You need to use workarounds every few weeks to get the same result as before.

I was hoping for a more mature project management from Redhat and ansible 2.0, but let this be a warning for the newcomers, that ansible needs upkeep.

[jefflill]

Could you please write this warning out to STDERR instead of STDOUT?

[WARNING] Ansible is in a world writable directory...

I'm seeing this message when I'm decrypting a variables file to STDOUT and I'm going to have to hack some special code node to watch for and strip this line out.

[kcd83]

Oh ha, this seems to work

export ANSIBLE_CONFIG=./ansible.cfg

Throw that in any vagrant/docker/wsl setups

[thegreatjerboa]

All these workarounds are great to know, but I think it is ridiculous assumption, and to have no possible workaround with inline ansible-playbook flags. I am now spending my day updating 40 build jobs with hacky workarounds, for breaking changes that were introduced in a patch version change! And all these builds run in short lived containers in which a single automated user has access to, so this dangerous world writable security hole you are protecting me from is completely invalid assumption.

[nitzmahone]

Quick update: we're not ignoring this- we're looking at a few different ideas to preserve the security fix of not reading config from an unprotected cwd. Trust me, what shipped in response to the recent CVEs around this was a very measured approach compared to some of the draconian measures being floated.

That said, I'm sure we can come up with a refinement or workaround to support these "world-writable-but-not-really" cases.

@thegreatjerboa Can you be more specific about your setup? I'm curious why you're implicitly reading ansible.cfg from cwd rather than a fixed location (which should work fine with world-writable- if not, it's a bug).

[abadger]

@jefflill I'm working on a proposal to fix the more general problem there (that almost all warnings and errors, as well as verbose debugging type information) are going to stdout instead of stderr. unfortunately, I keep getting pulled onto other problems...

[thegreatjerboa]

@nitzmahone it is same-dir-as-playbook. We have a git repo per playbook that gets run on checkin. The ansible.cfg and playbook are the top level of the repo, which is also the CWD when it runs.

[bcoca]

playbook dir is not looked at for ansible.cfg

[soar]

export ANSIBLE_CONFIG=./ansible.cfg

is NOT working for me, still getting

 [WARNING] Ansible is in a world writable directory (/mnt/c/Users/soar/projectdir), ignoring it as an ansible.cfg source.

with ansible 2.6.2

[abadger]

As I asked before... Does it actually pick up the config file despite
printing that warning?

The logic was printing the warning even if it was used due to
ANSIBLE_CONFIG.

[abadger]

43583 fixes the warning and should be merged later today to devel (backports to follow)

[nicolaibaralmueller]

Having the same issue today after upgrade. We are using this in production so right now our customer reports don't work. Please provide a fix for this.

[abadger]

This has now been fixed in devel via https://github.com/ansible/ansible/pull/43583 Backports for 2.6 and 2.5 are in the two PRs https://github.com/ansible/ansible/pull/43648 and https://github.com/ansible/ansible/pull/43649 and the backport has also been merged to stable-2.4 should there be another 2.4.x release.

What is in the fix?

• Documentation explaining the security risk and pointing to the right way of fixing it (mounting the filesystem so that the user and group that needs to access ansible.cfg can do so rather than mounting the directory world writable.
• Pointers to blog posts explaining how to do this for both vagrant and WSL (Vagrant doesn't appear to have anything more official than blog posts to explain and the WSL feature has both official documentation and a blog post which explains in more detail how to mount the filesystems).
• Documentation that explains that setting ANSIBLE_CONFIG to the config file you need can be used if you really must have it in a world writable directory as asked for by @AngellusMortis and @zoredache
• A fix for the warning about skipping the directory so that it doesn't appear that the config file is being skipped when it is both in a world writable current working directory AND specified in ANSIBLE_CONFIG.

If you still experience this issue while testing the devel branch please open a new issue to let us know what the exact symptoms are so that we can try to reproduce.

[realtebo]

If it could be usefull as use case, we use ansible in a vmware workstation ubuntu machine, using a shared folder that point to a phisical location.

Initially this mount location was created for mistake with 777 permissions. We reduced it to 755.

[siran]

I have set ANSIBLE_CONFIG environmental variable to teh absolute path to the ansible.cfg filename (/path/to/ansible.cfg), and I'm still getting the message: [WARNING] Ansible is in a world writable directory ...

$ ansible --version
 [WARNING] Ansible is in a world writable directory (/c/Users/my/path/to/ansible), ignoring it as an ansible.cfg source.
ansible 2.6.2
  config file = /path/to/ansible.cfg
  configured module search path = [u'/home/me/.ansible/plugins/modules', u'/usr/share/ansible/plugins/modules']
  ansible python module location = /usr/lib/python2.7/dist-packages/ansible
  executable location = /usr/bin/ansible
  python version = 2.7.12 (default, Dec  4 2017, 14:50:18) [GCC 5.4.0 20160609]

[abadger]

If you can test that against the devel branch or one of the PRs with backports to 2.6 or 2.5, that would be great. Otherwise, you can wait for 2.6.3 to come out and try it there.

[abadger]

The documentation that was part of the patch has links to information for
both vagrant and windows on how to mount filesystems with non world
writable directories:
https://docs.ansible.com/ansible/devel/reference_appendices/config.html#avoiding-security-risks-with-ansible-cfg-in-the-current-directory

Do those pieces of information not work for you?

On Fri, Aug 17, 2018, 3:23 AM Whidegroup [e-mail] wrote:

As soon as we have 2.6.3 version - now there should be an idea to make it
work under Windows machine. Can anybody advice about setting up the
vagrant/ansible combo to work properly specifying path to .cfg file?

—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/ansible/ansible/issues/42388#issuecomment-413823645,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAMxWhtxSRE6GQW6ZYJflqydXhrQW-FDks5uRpmLgaJpZM4VEmwB
.

[automateyournetwork]

I have Ubuntu installed on Windows 10 along with the WSL

I have added the following to my /etc/environment

ANSIBLE_CONFIG="/etc/ansible/ansible.cfg"

I am still getting the error

How did those who added the ANSIBLE_CONFIG environment variable make it work?

[abadger]

Can you open a new ticket with details on your setup, output, and how to reproduce? The latest 2.6 and 2.7 releases should work without a warning message if ANSIBLE_CONFIG is set

[tamusjroyce]

export ANSIBLE_CONFIG=./ansible.cfg

If it is an ansible.cfg in your current directory, not sure why you wouldn't allow it, since you navigate there. But having ANSIBLE_CONFIG is great! And considering security is way better than ignoring it. Thank you!!!