A few things: - It is not just the 'python interpreter', modules can be written in any language or even be binaries, modules that 'ship with Ansible' are Powershell and Python, but that is not a limitation of the engine, which makes it even harder to deal with.
- As much as 'per command granular permissions' would be nice to have, it is almost impossible given the nature of the dynamic payload and the reliance on systemcalls other than shell - I had a working branch with something close to what you desire, but using 'sudo cached credential initiator' + sudo wrapper in 'run_command' , this did not work well and basically only covered shell/command modules when the playbook author did exactly what was expected from them by the fine grained permissions ... which they could do just by sudo themselves (- shell: sudo ...) in the play instead of using become, so it never went anywhere. This is something we have been considering for years, and after many attempts we have not found something worthwhile merging into core. I would argue the closest we can get to this is doing something like the mitogen project, running the become plugins themselves at the remote via a temporary agent, but then this also limits us to python in many respects and removes several abilities (changing become/connection/interpreter settings per loop item, for example). ---------- Brian Coca -- You received this message because you are subscribed to the Google Groups "Ansible Development" group. To unsubscribe from this group and stop receiving emails from it, send an email to ansible-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-devel/CACVha7cJgP7xg4%3DLWg-ZMStq-FGY%3DXtJWrK8YDpjHM8dO_gu%2BQ%40mail.gmail.com.
