> > Also note that while run_command is used by some modules, the vast > majority use APIs instead of running commands, so become is more > geared to running the modules themselves [...] > what you ask for is not w/o reason, it is a niche use for a minority of > modules and pushes > against the desired design for most other use cases.
I agree "it is a niche use for a minority of modules" [currently] but I disagree in that it would "push against the desired design". Although this discussion may slide a bit away from the `become` vs `action plugins`, please let me question the "security" part of such a redesign based on "security". 1. *Granular permissions* are a fundamental aspect of security. 2. Currently, an Ansible task can *not* be run with elevated privileges without running the whole python interpreter with elevated privileges even if the actual task was `git pull` or `curl -o` > I understand the request, but the push is to separate those concerns > as both from a security and simplicity perspective, action plugins > should not be able or care about 'become settings', 3. Given I come up with a prototype of an hardened Ansible task execution mechanism (for some modules) the "concerns" are not so independent as one could believe from a naive "code purity" standpoint. 3. And from a security perspective, more *granular* and *limited* privileges is clearly more desirable and more straightforward than removing some (useful) variables from a python function scope. (The former is a tangible security gain while the later an hypothetical mean for such a goal) In consequence, I don't believe the abstract security of an internal code-path refactor is significant in comparison of the actual gain of running `composer`, `git` (and many more actually) on a host in a *safe* way (instead of adding `/usr/bin/python3` to /etc/sudoers) I believe this example is enough to limit the apparent "separation of concerns": `action plugins` have a (proven) legitimacy to care about `become` settings -- 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/20220713165430.GB1731583%40acer.
