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 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 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…
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 likesudo 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.
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.
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:
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 -
