[Enhancement] Disable jinja2 autoescape feature for some modules that use Ansible template

[tibidi]

Is there an existing issue for this?

• [X] There are no existing issues.

Ansible module

zos_job_submit

Enhancement or feature description

With the zos_job_submit module when we use a template as source, HTML/XML special characters will be escaped because the jinja2 autoescape feature is enabled in the code. So this code for example:

Vars:

template_values:
  jobcard: "TESTTE JOB 'WD-TEST',MSGLEVEL=(1,1),MSGCLASS=R"

Template

//{{template_values.jobcard}}

Will be converted to:

//TESTTE JOB 'WD-TEST',MSGLEVEL=(1,1),MSGCLASS=R

We need to explicitly disable autoescaping with:

//{{template_values.jobcard | safe }}

Or

{% autoescape false -%}
//{{template_values.jobcard}}
{%- endautoescape %}

For zos_job_submit autoescape should be disabled by default. Or we should have a way to disable it. In template_parameters for example.

[ddimatos]

My comment does not reflect rejection or acceptance of the issue, while I do see value in disabling autoescape, the are several challenges which a triage won't be able to appropriately size and we should take this as a research/development item to appropriately address.

Dating back to the decisions made; for our offering there was more value in investing in templating capabilities in multiple modules over a single template module. This drove our decision to use Jinja template Environment. In this environment implementation, we consciously elected to enable autoescaping=true to ensure security was accounted for, primarily template injection.

For the initial templating release we did not expect that users having to decide what is safe and what is not using the safe would pose an issue with an example like so //{{template_values.jobcard | safe }} which tells Jinja the user has made an explicit decision to claim the template literal is safe for no interpretation. Which leads me to my next point, while we are not discounting the usefulness to disable autoescape we plan to spend some time reviewing our modules execution paths to ensure security remains a primary focus.

The second issue is the design we chose, we went with a module_util/template.py which is shared among several modules where each module has only some interest in disabled autoescape achieved by instructing the routine with disabled_extensions.

For example, zos_job_submit would be interested in disabling autoescape for JCL, zos_script would be interested disabling autoescape for sh, rexx, py, while zos_copy might might be simply txt, this means we would prefer an architecture where modules could indicate without user input what they want to enable autoescape dynamically, for zos_job_submit, this might look like:

auto_reload=auto_reload,
            autoescape=select_autoescape(
    disabled_extensions=('jcl', 'JCL'),
    default_for_string=True,
    default=True,
)

Lastly, we probably would want to build a fail safe into the architecture with the ability to enable/disable autoescape since we would be making such modifications anyhow, in case we ever need to expose this through our module as a user option but plan to keep it initially internal.

My recommendation is that we evaluate this on:

• security first (template injection) which my thoughts are we are safe from given we are not templating on the controller to give up control on the controller thus permitting access to the managed node.
• Expanded architecture to allow for modules to request the types they want autoescaped
• Internal option/boolean to disable autoescape in case we need that in the future

Create an epic, manage the issues accordingly as git issues.

[adn1107]

Experience this issue myself:

I am using zos_job_submit with the use_template option and it failed. My env: zos_core : 1.10.0 pyz: 3.11.0 zoau: 1.3.0.0

    - name: Get expiring certs report for {{ hc_check }}
      ibm.ibm_zos_core.zos_job_submit:
        src: '{{ playbook_dir }}/HZSPRINT.J2'
        location: local
        use_template: true
      register: hc_job_output

{{ JOB_CARD }} //HZSPRINT EXEC PGM=HZSPRNT,TIME=1440,REGION=0M,PARMDD=SYSIN //SYSIN DD *,DLM='@@' CHECK(IBMRACF,RACF_CERTIFICATE_EXPIRATION) ,EXCEPTIONS @@ //SYSOUT DD SYSOUT=A,DCB=(LRECL=256) //

defaults file for print_hc_buffer

JOB_CARD: |- //HZSPRINT JOB 'IMS SYSTEM', // MSGCLASS=H,MSGLEVEL=(1,1),CLASS=A, // NOTIFY=&SYSUID

***** TOP OF DATA **** J E S 2 J O B L O G -- S Y S T E M S 2 -- N O D E N 1

15.21.42 JOB20727 ---- THURSDAY, 31 OCT 2024 ----
15.21.42 JOB20727 IRR010I USERID ALICIA IS ASSIGNED TO THIS JOB.
15.21.42 JOB20727 IEFC452I HZSPRINT - JOB NOT RUN - JCL ERROR 028
------ JES2 JOB STATISTICS ------
10 CARDS READ
23 SYSOUT PRINT RECORDS
0 SYSOUT PUNCH RECORDS
1 SYSOUT SPOOL KBYTES
0.00 MINUTES EXECUTION TIME
1 //HZSPRINT JOB 'IMS SYSTEM', JOB20727
2 // MSGCLASS=H,MSGLEVEL=(1,1),CLASS=A,
3 // NOTIFY=&SYSUID
4 //HZSPRINT EXEC PGM=HZSPRNT,TIME=1440,REGION=0M,PARMDD=SYSIN
5 //SYSIN DD *,DLM='@@'
6 //SYSOUT DD SYSOUT=A,DCB=(LRECL=256)
7 //
STMT NO. MESSAGE
1 IEFC620I UNIDENTIFIABLE CHARACTER ; ON THE JOB STATEMENT
2 IEFC605I UNIDENTIFIED OPERATION FIELD
3 IEFC605I UNIDENTIFIED OPERATION FIELD
**** BOTTOM OF DATA **