# Job Template Permissions **URL:** \ **Category:** Project Discussions\ **Tags:** dev, awx\ **Created:** [September 29, 2023, 2:07pm UTC](https://forum.ansible.com/t/job-template-permissions/1195 "2023-09-29T14:07:18Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![AlanCoding](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/alancoding/32/301_2.png) [@AlanCoding](https://forum.ansible.com/u/AlanCoding)\ **Post date:** [September 29, 2023, 2:07pm UTC](https://forum.ansible.com/t/job-template-permissions/1195/1 "2023-09-29T14:07:18Z")
I would like discuss this issue: > > > \### Please confirm the following > > \- \[X\] I agree to follow this project's \[code o…f conduct\](https://docs.ansible.com/ansible/latest/community/code\_of\_conduct.html). > \- \[X\] I have checked the \[current issues\](https://github.com/ansible/awx/issues) for duplicates. > \- \[X\] I understand that AWX is open source software provided for free and that I might not receive a timely response. > > \### Bug Summary > > When attempting to switch to a new project and update the playbook dropdown, the playbook dropdown is greyed and not selectable. This only occurs when the template admin does not have read permissions to the project being changed from. It is expected that the template admin be able to switch to their project and select their playbook without requiring read access to the old project. > > > > \### AWX version > > devel > > \### Select the relevant components > > \- \[\] UI > \- \[X\] API > \- \[\] Docs > \- \[\] Collection > \- \[\] CLI > \- \[\] Other > > \### Installation method > > kubernetes > > \### Modifications > > no > > \### Ansible version > > 2.14.0 > > \### Operating system > > centos9 > > \### Web browser > > \_No response\_ > > \### Steps to reproduce > > 1. create a normal user with job template admin to an org or template admin > 2. create a job template or use template to which user was granted admin > 3. ensure job template has inventory and project specified which the created user does not have at least \`use\` > 4. create project and/or inventory and grant user \`use\` > 5. log in as user and attempt to edit project or inventory > > \### Expected results > > Able to change project or inventory to one which the user has access. > > \### Actual results > > 403 error after allowing selection of the project > > \### Additional information > > \_No response\_ **Current Job Template (JT) Permissions** To edit certain fields (like name/description/forks), you just needed admin\_role to the JT. To edit other “sensitive” scalar fields (like allow\_simultaneous/job\_type/ask\_forks\_on\_launch), you need both admin\_role to the JT and use\_role to a collection of associated resources - which are project and inventory… also read\_role to execution environment. To edit direct _relational_ fields, which are project, inventory, and execution environment, you need - admin\_role to the JT - relevant role to the new item, like use\_role for project - all the permissions already mentioned about “sensitive” fields, which means needing permission to all existing direct relational fields - so current project, inventory, and execution environment **Most Reasonable Permissions** Here’s a branch that I think shows what I think is most sensible: > **[Comparing ansible:devel...AlanCoding:jt\_permission\_ideal · ansible/awx](https://github.com/ansible/awx/compare/devel...AlanCoding:jt_permission_ideal?expand=1)** > > AWX provides a web-based user interface, REST API, and task engine built on top of Ansible. It is one of the upstream projects for Red Hat Ansible Automation Platform. - Comparing ansible:devel...A... This argues that permission to edit a JT should be: - admin\_role to the JT, and this is all if it is a scalar field - relevant role to any new field being attached, like use\_role to a project **Thoughts** Current permissions are poorly documented (if at all), and if the user got a permission error due to one of the corner cases we have coded for, it wouldn’t be a coherent denial of permission, but just a source of frustration. The “sensitive” field list has not been maintained over time so it includes much more than it should, even if it is a good idea. However, I think we should take serious at least a little bit of the idea of what I would call **inventory protection** , because I think that’s the only reasonable idea from current permission rules. If someone has admin\_role to a JT, they should be able to change anything they wish if they don’t have use\_role to the inventory. For the most part, I think that should be limited to changing project/playbook/EE, because these dictate how the inventory is acted on. I could be convinced otherwise on this idea of **inventory protection**. If we keep any vestige of that idea, there should be thought given to the user experience of someone receiving a permission error, and docs to support it. ---
**Author:** ![maxamillion](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/maxamillion/32/98_2.png) [@maxamillion](https://forum.ansible.com/u/maxamillion)\ **Post date:** [September 29, 2023, 5:22pm UTC](https://forum.ansible.com/t/job-template-permissions/1195/2 "2023-09-29T17:22:23Z")
@AlanCoding Is there any concern of sensitive data leaking if an user has admin\_role to a JT but not use\_role to the inventory with the proposed change? I’m thinking of scenarios where someone is storing variable data in an inventory that is restricted for one reason or another. This also spawns a question in my mind as to how AWX combines inventory and secrets data with the JT (pardon my ignorance on the topic, I still have much to learn about the inner workings of AWX). ---
**Author:** ![AlanCoding](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/alancoding/32/301_2.png) [@AlanCoding](https://forum.ansible.com/u/AlanCoding)\ **Post date:** [September 29, 2023, 7:07pm UTC](https://forum.ansible.com/t/job-template-permissions/1195/3 "2023-09-29T19:07:45Z")
Yeah, those concerns are exactly why these restrictions exist in the first place. People do store secrets in inventory variable data, and with control of the playbook you can get this out. However, I think that would be a bigger concern for not having use\_role to the credential, and using access to the project/playbook to get that data out. It’s probably not uncommon that someone has a general “debug any variable” lying around in their project… > So the ability to change the playbook can equate to the ability to go print all the variables. ---
**Author:** ![maxamillion](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/maxamillion/32/98_2.png) [@maxamillion](https://forum.ansible.com/u/maxamillion)\ **Post date:** [October 5, 2023, 7:21pm UTC](https://forum.ansible.com/t/job-template-permissions/1195/4 "2023-10-05T19:21:07Z")
Understood, thanks! 👍