# Writing a custom become plugin

**URL:** <https://forum.ansible.com/t/writing-a-custom-become-plugin/38990>\
**Category:** Get Help\
**Tags:** plugin\
**Created:** [December 9, 2024, 11:21am UTC](https://forum.ansible.com/t/writing-a-custom-become-plugin/38990 "2024-12-09T11:21:02Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![bvx54](https://avatars.discourse-cdn.com/v4/letter/b/3d9bf3/32.png) [@bvx54](https://forum.ansible.com/u/bvx54)\
**Post date:** [December 9, 2024, 11:21am UTC](https://forum.ansible.com/t/writing-a-custom-become-plugin/38990/1 "2024-12-09T11:21:02Z")

</div>

where do i get assistance on writing become plugins?  
There’s very little info on how to get started, debug, what all the stuff means etc.  
I had to end up reading the entire SSH/su/init/become code to work it all out for my self… sadly

currently have a situation where i can only run ´sudo su -´ and then a password entered after the prompt.

the standard ansible “become” functionality doesnt support this.

I’ve had a look in the community plugins and nothing there works either. the [sudosu become plugin](https://github.com/djmattyg007/community.general/blob/a55c96d5c14661be3257cf3b465cbf8b301435eb/plugins/become/sudosu.py) comes close but that one runs  
´sudo su - ´ whereas my terminal session is only allowed to do do `sudo su -`

I found [this excellent example](https://unix.stackexchange.com/a/786836) of a user that runs just `sudo su -` then pipes in the second command, but this user had passwordless sudo, and hence hasnt coded in a prompt.

im using the example above, but when i add a prompt in, i can see the prompt coming up in the log, but the become machinery doesnt seem to match the prompt, and hence doenst send in the become password…

---

<div class="post-metadata">

**Author:** ![Denney-tech](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/denney-tech/32/1556_2.png) [@Denney-tech](https://forum.ansible.com/u/Denney-tech)\
**Post date:** [December 9, 2024, 2:57pm UTC](https://forum.ansible.com/t/writing-a-custom-become-plugin/38990/2 "2024-12-09T14:57:06Z")

</div>

You might be able to use the default become method and user to run `su -` commands as root. This will require your sudo password, but root doesn’t need the su password to work. It should work _like_ `sudo su -`, although I can’t say for sure that would work in your case if you have a sudo rule that only allows `sudo su -` explicitly. I had a similar case where I needed to use `su` to stop a database as a particular user, but instead of using become, I authenticated directly as root with an ssh key.

---

<div class="post-metadata">

**Author:** ![bcoca](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/bcoca/32/9269_2.png) [@bcoca](https://forum.ansible.com/u/bcoca)\
**Post date:** [December 9, 2024, 4:10pm UTC](https://forum.ansible.com/t/writing-a-custom-become-plugin/38990/3 "2024-12-09T16:10:33Z")

</div>

The reason we never implemented the sudosu plugin in core is that there are too many variations and each would require it’s own version of the plugin. The community one can be used as a starting point, but you’ll have to adapt that to your context. Also there is a limitation that ansible-core only handles 1 prompt, so in cases where your setup produces multiple prompts, you probably won’t be able to get a functional plugin.

In my personal campaign to end `sudo su -`:

- You can use PAM to make `su` take the executing user’s password instead the target user or even keys/certs (main reason sudo is present), but most will balk at dealing with pam.d files soo, see next entry
- You don’t need `su` as `sudo -i` == `sudo su -`. There is no need to use `su` as `sudo` can do the same (`-i` forces a login for sudo, what `-` does for `su`), you can even use `sudo -s` (same as `sudo su`) to do a ‘non interactive’ login, allowing you to avoid reading .profile/.shrc/.bashrc files.
- Having both means you are open to exploits on 2 suid executables, aside from being somewhat redundant and making many back and forth redundant system calls. This is almost irrelevant issue when dong manually, but adds up when you are doing it many times in parallel (like in automation/config management).
- Using `sudo` alone gives you more fine grain controlled on the environment variables.
- Using `sudo` alone allows you to query info about the original user. This is very useful for logging which admin did what as root.

---

<div class="post-metadata">

**Author:** ![bvx54](https://avatars.discourse-cdn.com/v4/letter/b/3d9bf3/32.png) [@bvx54](https://forum.ansible.com/u/bvx54)\
**Post date:** [December 12, 2024, 1:40pm UTC](https://forum.ansible.com/t/writing-a-custom-become-plugin/38990/4 "2024-12-12T13:40:10Z")

</div>

Many thanks Brian this was **very** well reasoned! 🙂

sudo is definitely my preference but in this case i am restricted to one command `sudo su -`

in any case it looks like i can use Ansilbe Automation platform instead with differerent accounts without the `sudo su -` restriction.

---

<div class="post-metadata">

**Author:** ![bvitnik](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/bvitnik/32/4132_2.png) [@bvitnik](https://forum.ansible.com/u/bvitnik)\
**Post date:** [December 12, 2024, 6:29pm UTC](https://forum.ansible.com/t/writing-a-custom-become-plugin/38990/5 "2024-12-12T18:29:54Z")

</div>

> [@bcoca](#):
>
> You don’t need `su` as `sudo -i` == `sudo su -`.

While this is correct in most use cases, there are subtle differences in what environment variables are preserved/imported. At some point in time I have stumbled upon a blog article (or forum post) which did a comprehensive analysis of the differences. Unfortunately, I cannot find it any more. This one seems to be the closest one:

[https://forums.opensuse.org/t/sudo-vs-su-and-more/76510](https://forums.opensuse.org/t/sudo-vs-su-and-more/76510)

---

<div class="post-metadata">

**Author:** ![bcoca](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/bcoca/32/9269_2.png) [@bcoca](https://forum.ansible.com/u/bcoca)\
**Post date:** [December 12, 2024, 6:31pm UTC](https://forum.ansible.com/t/writing-a-custom-become-plugin/38990/6 "2024-12-12T18:31:01Z")

</div>

i made a point about sudo giving you fine grain control on environment variables, for me that is a plus. My point is not really against `su`, but against `sudo su -`

---

<div class="post-metadata">

**Author:** ![bvitnik](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/bvitnik/32/4132_2.png) [@bvitnik](https://forum.ansible.com/u/bvitnik)\
**Post date:** [December 12, 2024, 6:34pm UTC](https://forum.ansible.com/t/writing-a-custom-become-plugin/38990/7 "2024-12-12T18:34:17Z")

</div>

I agree… but for some reason, unknown to me, `sudo su -` is so much prevalent, especially in blog posts and tutorials.

---

<div class="post-metadata">

**Author:** ![bcoca](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/bcoca/32/9269_2.png) [@bcoca](https://forum.ansible.com/u/bcoca)\
**Post date:** [December 12, 2024, 6:36pm UTC](https://forum.ansible.com/t/writing-a-custom-become-plugin/38990/8 "2024-12-12T18:36:16Z")

</div>

lazy sysadmins … its a copy/paste from online irc that has persisted waaaay tooo looong and I’m on a mission to end it.
