Hello Sam, Thanks for the clarifications.
On 07/25/2018 07:46 PM, Sam Doran wrote: > I spoke with other Ansible Core devs to get some clarity on this change. > > This is not a change that is being made quickly, lightly, or without a > whole of bunch of reservation. In fact, that PR created by agaffney may > not be merged any time soon. He just wanted to get something started and > there is still ongoing discussion on that PR. It is definitely a WIP at > this point. > > The main reason for this change is that pretty much all of the Ansible > CVEs to date came from "fact injection", meaning a fact that contains > executable Python code Jinja will merrily exec(). Vars, hostvars, and > facts are different in Ansible (yes, this is confusing — sorry). All > vars go through a templating step. By copying facts to vars, it means > facts get templated controller side which could lead to controller > compromise if malicious code exists in facts. > > We created an AnsibleUnsafe class to protect against this, but stopping > the practice of injecting facts into vars would close the door > completely. It also alleviates some name collisions if you set a hostvar > that has the same name as a var. We have some methods that filter out > certain variables, but keeping facts and vars in separate spaces is much > cleaner. > > This also does not change how hostvars set via set_fact are referenced. > (set_fact should really be called set_host_var). Variables set with > set_fact are not facts and are therefore not inside the ansible_facts > dict. They are in the hostvars dict, which you can reference as {{ > my_var }} or {{ hostvars['some-host']['my_var'] }} if you need to look > it up from a different host. so if, for convenience, we do this: vars: a_mounts: "{{ hostvars[inventory_hostname].ansible_facts.mounts }}" That's completely acceptable and correct, and won't create any security issue, right? > > All that being said, the setting to control this behavior as Emilien > pointed out is inject_facts_as_vars, which defaults to True and will > remain that way for the foreseeable future. I would not rush into > changing all the fact references in playbooks. It can be a gradual process. > > Setting inject_facts_as_vars toTrue means ansible_hostname becomes > ansible_facts.hostname. You do not have to use the hostvars dictionary — > that is for looking up facts about hosts other than the current host. > > If you wanted to be proactive, you could start using the ansible_facts > dictionary today since it is compatible with the default setting and > will not affect others trying to use playbooks that reference ansible_facts. > > In other words, with the default setting of True, you can use either > ansible_hostname or ansible_facts.hostname. Changing it to False means > only ansible_facts.hostname is defined. > >> Like, really. I know we can't really have a word about that kind of >> decision, but... damn, WHY ?! > > That is most certainly not the case. Ansible is developed in the open > and we encourage community members to attend meetings > <https://github.com/ansible/community/blob/master/meetings/README.md> and add > topics to the agenda > <https://github.com/ansible/community/issues/325> for discussion. > Ansible also goes through a proposal process for major changes, which > you can view here > <https://github.com/ansible/proposals/issues?utf8=%E2%9C%93&q=is:issue+is:open>. > > You can always go to #ansible-devel on Freenode or start a discussion on > the mailing list > <https://groups.google.com/forum/#%21forum/ansible-devel> to speak with > the Ansible Core devs about these things as well. And I also have the "Because" linked to my "why" :). big thanks! Bests, C. > > --- > > Respectfully, > > Sam Doran > Senior Software Engineer > Ansible by Red Hat > sdo...@redhat.com <mailto:sdo...@redhat.com> > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Cédric Jeanneret Software Engineer DFG:DF
signature.asc
Description: OpenPGP digital signature
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev