Executable and non-executable inventory files should not be conflated

[dazwin]

I ran into the following error when running ansible-playbook -i [myinventory], using Vagrant on a Windows host:

ERROR: The file [myinventory] is marked as executable, but failed to execute correctly. If this is not supposed to be an executable script, correct this with `chmod -x [myinventory]`

The problem is that vboxfs (as does many other filesystem options) will set the execute permission on all files if mounted on a filesystem that isn't Unix-like such as FAT or NTFS.

My workaround is ugly - in Vagrant, I am mounting my source files a second time so that I can refer to a version of my inventory file without +x, such as:
config.vm.synced_folder ".", "/vagrant-nox", :mount_options => ["fmode=666"]

I consider the decision to execute an inventory file as a script based solely on its execute permission a bad idea. This is a non-obvious problem and a common use case - here as some examples of other users coming across the same problem:

• http://stackoverflow.com/questions/26859360/cant-use-ansible-inventory-file-because-it-is-executable
• https://groups.google.com/forum/#!topic/ansible-project/rAM6mOEjwv4
• Error when attempting to run vagrant up for the first time  phansible/phansible#71

It also allows a malicious user to execute a script with elevated privileges - all they'd need is write permission on a (non-script) inventory file.

A possible solution is to use a separate command line option if an executable inventory should be used, although this does not provide backwards compatibility.

[mindware]

I also ran into this very same issue. I agree with @dazwin and think alternatives should be taken into consideration.

[danthedeckie]

I've also been bitten by this, as we keep our production ansible directory on a (SMB) network share, which can then be mounted by any of our sys-admins. Currently I've had to create a stupid work-around script which copies the inventory (and host_vars and group_vars) out, chmod -x's them, and then uses that version. Very annoying.

[danthedeckie]

http://stackoverflow.com/questions/26859360/cant-use-ansible-inventory-file-because-it-is-executable
is another user having the same issue.

[majidaldo]

+1

[georgegeka]

I think it's a great idea , and the one that should be very easy to implement

[majidaldo]

heck as a first rough approach, ansible should know that .sh .exe .py .rb ...etc are executable and others are not.

[bcoca]

@majidaldo eh ... no, executable status on linux/unix is represented by the executable bit on a file, NOT by extension, that is a windows thing.

[majidaldo]

@bcoca i know but i'm implying that ansible could have a mode where it recognizes executables based on file extension.=> backward compat and makes people interested in this issue happy.

btw, i'm actually experimenting with ansible in cygwin. if i have to goof around too much with it a VM is with a shared folder is the only solution.

[bcoca]

no, mapping by extension is not a solution, we are not going to keep an extension registry in Ansible.

Aside from fixing the filesytem to report correctly on the executable bit, the other possible solution here is trying all the plugins in order and only failing at the end.

[brunitto]

+1 here

We have to use Windows notebooks under a strict company policy and our way to use ansible was to create a playbooks repository under Git and work as a Vagrant VM. I think that it is a very specific problem and it takes time to analyse and figure out how to merge this into a well defined architecture like Ansible.

Our workaround was to copy the main inventory file (within our repository at /vagrant) to /etc/ansible/hosts, using git pull hook. The limitation is that you can work with just one inventory file, but a well defined group counter attack this.

A believe that the @bcoca got the drive to solve this, using a plugin model, where if a executable file fails to execute it is parsed as inventory file.

[ramondelafuente]

+1, a fallback to parsing the file would have saved a lot of time here.

[naxhh]

As @dazwin said we had this issue in phansible. In fact a lot of users have complained about this. And is very confusing for them.

[cheesegrits]

Can this issue get some love?

[jschank]

I want to vote up this issue as well.
Perhaps inventory files with .ini, .txt or no extension should ignore the executable permission and be "static" and any dynamic inventories should be required to have an extension.

[apelliciari]

+1, it's annoying

[bcoca]

this is fixed in the merged #11643

[sergeytsivin]

+1, have the same issue. An additional option that disables dynamic inventory would solve the problem.

[sergeytsivin]

Sorry, I had this issue with ansible 1.9.4, it seems that the issue is fixed in 2.x series, I tested it with 2.0.0.2 and 2.0.1.0 and static inventory with executable bits set worked fine.

[brunitto]

I tested this with 2.x and worked gracefully.

[travisdetert]

What is this even trying to avoid? What is the intent here? (Honest question? )