Open Stack

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
> sdoran at redhat.com <mailto:sdoran at redhat.com>
> 
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

-- 
Cédric Jeanneret
Software Engineer
DFG:DF

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180726/24cb89ab/attachment.sig>