-
Notifications
You must be signed in to change notification settings - Fork 23.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Windows 10/WSL: Ansible cannot read ansible.cfg from NTFS mounts #42388
Comments
Files identified in the description: If these files are inaccurate, please update the |
Files identified in the description: If these files are inaccurate, please update the |
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. |
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 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 |
Maybe you could allow people to whitelist directories from this check via an environment variable? Something like I am not that good at python, but maybe something like this?
Then I can just set |
You can set the |
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 ***@***.***> 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
<#42388 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAMxWr8Z2LerEPWWmwZu1BR5RT9qgdnTks5uDwJ5gaJpZM4VEmwB>
.
|
i am using vagrant on windows to run ansible playbooks. Its still failing even after setting ansible_config value. [root@controller ]# echo $ANSIBLE_CONFIG [root@controller mapr-ansible-paysafe]# ls -lh ansible.cfg [root@controller ]# ansible -m ping all -i environment/XXXX/cluster.ini -v Temporary Solution |
The |
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? |
|
Problems on Vagrant shared folder too, it is 0777 only mode for folders in this case and can't be changed. |
I think I found a solution for 2.6.1 and so on... Create this file in your wsl: /etc/wsl.conf Content:
After that all /mnt/c/foo will have different folder permissions (not 777 any more) and you will be able to use chmod. |
Okay, the comment in #42388 (comment) 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. |
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 |
This is needed as not all platforms support and/or accept the given parameters and sometimes one could get the following message which would prevent from the VM to start at all, e.g.: ``` Failed to mount folders in Linux guest. You've specified mount options which are not supported by "prl_fs" file system. Invalid mount options: ["dmode=775,fmode=664"] ``` Also the original issue only seems to affect Windows platform with virtualbox as hypervisor, as this can be seen at: ansible/ansible#42388
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":
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. |
Solution for Vagrant, edit Vagrantfile and add config.vm.synced_folder "../my-folder", "/home/vagrant/my-folder", mount_options: ["dmode=775"] |
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. |
Could you please write this warning out to STDERR instead of STDOUT?
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. |
Oh ha, this seems to work
Throw that in any vagrant/docker/wsl setups |
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. |
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). |
@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... |
@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. |
* Also add unittests for the find_ini_config_file function * Add documentation on world writable current working directory config files can no longer be loaded from a world writable current working directory but the end user is allowed to specify that explicitly. Give appropriate warnings and information on how. Fixes ansible#42388
is NOT working for me, still getting
with |
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.
|
#43583 fixes the warning and should be merged later today to devel (backports to follow) |
Only print warning when ansible.cfg is actually skipped * Also add unittests for the find_ini_config_file function * Add documentation on world writable current working directory config files can no longer be loaded from a world writable current working directory but the end user is allowed to specify that explicitly. Give appropriate warnings and information on how. Fixes ansible#42388
…nsible#43583) Only print warning when ansible.cfg is actually skipped * Also add unittests for the find_ini_config_file function * Add documentation on world writable current working directory config files can no longer be loaded from a world writable current working directory but the end user is allowed to specify that explicitly. Give appropriate warnings and information on how. Fixes ansible#42388 (cherry picked from commit 30662be) Co-authored-by: Toshio Kuratomi <a.badger@gmail.com>
…nsible#43583) Only print warning when ansible.cfg is actually skipped * Also add unittests for the find_ini_config_file function * Add documentation on world writable current working directory config files can no longer be loaded from a world writable current working directory but the end user is allowed to specify that explicitly. Give appropriate warnings and information on how. Fixes ansible#42388 (cherry picked from commit 30662be) Co-authored-by: Toshio Kuratomi <a.badger@gmail.com>
…43583) Only print warning when ansible.cfg is actually skipped * Also add unittests for the find_ini_config_file function * Add documentation on world writable current working directory config files can no longer be loaded from a world writable current working directory but the end user is allowed to specify that explicitly. Give appropriate warnings and information on how. Fixes #42388. (cherry picked from commit 30662be) Co-authored-by: Toshio Kuratomi <a.badger@gmail.com>
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. |
This has now been fixed in devel via #43583 Backports for 2.6 and 2.5 are in the two PRs #43648 and #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?
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. |
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. |
I have set ANSIBLE_CONFIG environmental variable to teh absolute path to the ansible.cfg filename (
|
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. |
…43583) Only print warning when ansible.cfg is actually skipped * Also add unittests for the find_ini_config_file function * Add documentation on world writable current working directory config files can no longer be loaded from a world writable current working directory but the end user is allowed to specify that explicitly. Give appropriate warnings and information on how. Fixes #42388 (cherry picked from commit 30662be) Co-authored-by: Toshio Kuratomi <a.badger@gmail.com>
…43583) (#43649) Only print warning when ansible.cfg is actually skipped * Also add unittests for the find_ini_config_file function * Add documentation on world writable current working directory config files can no longer be loaded from a world writable current working directory but the end user is allowed to specify that explicitly. Give appropriate warnings and information on how. Fixes #42388 (cherry picked from commit 30662be) Co-authored-by: Toshio Kuratomi <a.badger@gmail.com>
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 ***@***.***> 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
<#42388 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAMxWhtxSRE6GQW6ZYJflqydXhrQW-FDks5uRpmLgaJpZM4VEmwB>
.
|
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? |
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 |
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!!! |
SUMMARY
Ansible 2.6.1 added #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
COMPONENT NAME
lib/ansible/config/manager.py
ANSIBLE VERSION
CONFIGURATION
N/A
OS / ENVIRONMENT
Windows 10 + any WSL distro
STEPS TO REPRODUCE
sudo pip install ansible==2.6.1
ansible.cfg
some where on yourC:\
drivecd
to Directory from WSLEXPECTED RESULTS
ansible.cfg
files on Windows mounts in WSL are not ignoredACTUAL RESULTS
ansible.cfg
file is ignored with the following warning:The text was updated successfully, but these errors were encountered: