# Why is using args from variables considered unsave? **URL:** \ **Category:** Ansible Project\ **Created:** [March 16, 2017, 10:02am UTC](https://forum.ansible.com/t/why-is-using-args-from-variables-considered-unsave/23989 "2017-03-16T10:02:09Z")\ **Posts on this page:** 10\ **Page:** 1
**Author:** ![Michal\_Czeraszkiewic](https://avatars.discourse-cdn.com/v4/letter/m/df788c/32.png) [@Michal\_Czeraszkiewic](https://forum.ansible.com/u/Michal_Czeraszkiewic)\ **Post date:** [March 16, 2017, 10:02am UTC](https://forum.ansible.com/t/why-is-using-args-from-variables-considered-unsave/23989/1 "2017-03-16T10:02:09Z")
I’m trying out this playbook: ` ---
**Author:** ![Parag\_Doke](https://avatars.discourse-cdn.com/v4/letter/p/9f8e36/32.png) [@Parag\_Doke](https://forum.ansible.com/u/Parag_Doke)\ **Post date:** [December 7, 2017, 6:12am UTC](https://forum.ansible.com/t/why-is-using-args-from-variables-considered-unsave/23989/2 "2017-12-07T06:12:43Z")
I am also looking forward to understand why this is being deprecated. Also, if anyone knows an alternative, please do share. It looks like this deprecation warning was first introduced via commit [https://github.com/ansible/ansible/commit/e526743b4f91a571f48bff4280ce5e441f72a292#diff-76ffc0551f8cf3d6255500316568e60bR242](https://github.com/ansible/ansible/commit/e526743b4f91a571f48bff4280ce5e441f72a292#diff-76ffc0551f8cf3d6255500316568e60bR242) by jimi-c. The commit message/comment refers to a debate on whether to have this added to 2.0. Hopefully, if that discussion is captured in text somewhere, a link to that will help understand the reasoning behind. ---
**Author:** ![jimi](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/jimi/32/3491_2.png) [@jimi](https://forum.ansible.com/u/jimi)\ **Post date:** [December 19, 2017, 8:21pm UTC](https://forum.ansible.com/t/why-is-using-args-from-variables-considered-unsave/23989/3 "2017-12-19T20:21:16Z")
We consider this unsafe due to the fact that, if the variable is based on a fact of some kind, your tasks could start doing unexpected or malicious things (in the event that the remote system is compromised in some way). In your example, you could still simplify your task by simply restructuring it a bit: - file: src: “{{item.src}}” dest: “{{item.dest}}” state: link with\_items: ---
**Author:** ![Olivier\_Cervello](https://avatars.discourse-cdn.com/v4/letter/o/c68b51/32.png) [@Olivier\_Cervello](https://forum.ansible.com/u/Olivier_Cervello)\ **Post date:** [December 21, 2017, 5:06pm UTC](https://forum.ansible.com/t/why-is-using-args-from-variables-considered-unsave/23989/4 "2017-12-21T17:06:40Z")
I’m sorry but your solution is very limited in scope, and not flexible at all (something we expect from modern automation software). **Example with file resource:** Let’s say I want 2 symlinks **and** a file to be removed, and don’t want to bother declaring multiple variables / tasks for it (after all, Ansible has one resource valid for both those actions, so I should be able to define a single variable, and a single task). ---
**Author:** ![sivel](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/sivel/32/1198_2.png) [@sivel](https://forum.ansible.com/u/sivel)\ **Post date:** [December 21, 2017, 5:11pm UTC](https://forum.ansible.com/t/why-is-using-args-from-variables-considered-unsave/23989/5 "2017-12-21T17:11:09Z")
Instead of `default(None)` you should be using `default(omit)` it was designed exactly for this purpose, and will not override the default. In instructs ansible to not pass that provided argument on to the module. ---
**Author:** ![Olivier\_Cervello](https://avatars.discourse-cdn.com/v4/letter/o/c68b51/32.png) [@Olivier\_Cervello](https://forum.ansible.com/u/Olivier_Cervello)\ **Post date:** [January 2, 2018, 10:42pm UTC](https://forum.ansible.com/t/why-is-using-args-from-variables-considered-unsave/23989/6 "2018-01-02T22:42:58Z")
Ok, but I consider this as a workaround and not a solution (cf. comment I wrote above). ---
**Author:** ![Jim\_Ficarra](https://avatars.discourse-cdn.com/v4/letter/j/9d8465/32.png) [@Jim\_Ficarra](https://forum.ansible.com/u/Jim_Ficarra)\ **Post date:** [January 25, 2018, 8:17pm UTC](https://forum.ansible.com/t/why-is-using-args-from-variables-considered-unsave/23989/7 "2018-01-25T20:17:31Z")
> **with\_items** is acceptable in the situations where you intend to loop over items, not pass in variable that aren’t meant to be iterated over. This deprecation has implications for **include\_role** and **import\_role** where the task parameters certainly will come from variables. An additional 2 cents - there doesn’t seem to be much offered in the way of alternatives - honestly **with\_items** is not an appropriate alternative for use cases not involving iteration. What is Red Hat offering for an alternative other than **with\_items**? ---
**Author:** ![Geoffroy\_Desvernay](https://avatars.discourse-cdn.com/v4/letter/g/7993a0/32.png) [@Geoffroy\_Desvernay](https://forum.ansible.com/u/Geoffroy_Desvernay)\ **Post date:** [January 27, 2018, 2:05pm UTC](https://forum.ansible.com/t/why-is-using-args-from-variables-considered-unsave/23989/8 "2018-01-27T14:05:11Z")
2 cts more here: I’m in the same kind of headache with zfs module: the list of possible zfs properties depends on the zfs implementation, and is very long (seems like a bas idea to fix this list anywhere). Most people need to set 1 or 2 properties, but some uses need much more… And I really think that if an attacker can write in ansible’s inventory… I’d consider _all_ systems manageable from ansible as corrupted. I think about it like any program’s config: the program should reject invalid items if possible. In the zfs module’s case, it should implement thousands lines of code (with associated bugs) to be able to do this correctly (or not correctly…). The other option is to limit it’s functionnality to a little subset of what it can do today. Same thing with cron module (a bit mode “workaround-able”). The people (or program) responsible for inventory’s variable _have to_ understand what they do, please don’t try to make ansible too much intelligent (KISS please 😉 ---
**Author:** ![Geoffroy\_Desvernay](https://avatars.discourse-cdn.com/v4/letter/g/7993a0/32.png) [@Geoffroy\_Desvernay](https://forum.ansible.com/u/Geoffroy_Desvernay)\ **Post date:** [January 27, 2018, 2:14pm UTC](https://forum.ansible.com/t/why-is-using-args-from-variables-considered-unsave/23989/9 "2018-01-27T14:14:21Z")
Forgot a killer-feature of zfs: you can define your own properties… no one is able to list possibilities here. ---
**Author:** ![vasgouv](https://avatars.discourse-cdn.com/v4/letter/v/f07891/32.png) [@vasgouv](https://forum.ansible.com/u/vasgouv)\ **Post date:** [July 2, 2018, 12:56pm UTC](https://forum.ansible.com/t/why-is-using-args-from-variables-considered-unsave/23989/10 "2018-07-02T12:56:38Z")
Hello, I agree that this is a needed feature that simplifies code and enhances readability. I opened a feature request to make this a configuration option rather than removing it, if they insist on deprecating it. [https://github.com/ansible/ansible/issues/42192](https://github.com/ansible/ansible/issues/42192) V.G.