Using sudo with the raw command is broken when executable commands are restricted in sudoers

[interesse]

I'm using ansible in an environment where I can only use an unprivileged user and commands with sudo that are explicitly allowed in the sudoers file.
Using standard ansible modules is therefor out of reach as allowing to run arbitrary python code in sudoers would not be appreciated.

What used to work was using the raw module. This resulted in a remote call similar to

sudo /bin/bash -c command --with params

and that could be allowed in sudoers.

Since commit ea2ec62 this doesn't work any more. Now the remote call looks similar to this:

sudo /bin/bash -c 'echo SUDO-SUCCESS-pfzrbklycnjwobmyadpefvdcdwfizbwt; command --with params'

and I didn't find a way to allow that in sudoers without opening sudo for arbitrary commands.

As sudo is meant to be used with restricted command access and it is not mentioned in the ansible documentation that the sudo support is limited in this way and it used to work before, I believe this is a bug.

[mpdehaan]

So your constrained use of sudo isn't how Ansible works.

We use sudo to invoke modules, so you can't lock things down on a per module basis.

While I understand your use of constrained "only use the raw module" Ansible, that's also not our primary use case, so I'm not inclined to say this is a problem we need to fix, as your environment restrictions also mean you can't use 95% of Ansible.

It may be nice to be able to not do the "sudo success checking" stuff with raw, but for most people that's a valuable feature too.

I think it would just be better if we document the flavor of our sudo capabilities more directly, which I will file a docs ticket to take care of.

[nanobeep]

For anyone else hitting this issue, here's a quick write-up of a couple possible workarounds: https://gist.github.com/nanobeep/3b3d614a709086ff832a

[ghost]

I concur with this bug or new feature request.
I have a problem, I am responsible for the servers, configurations, deployment etc... and I am happily using Ansible.
Now we have more and more users / developers that want to use Ansible to deploy their service / applications from all sorts of Ansible playbook they find in internet.
And I want to secure my server to ensure that they don't install or modify the server in ways that disrupt the integrity of my servers.
Yes, I am already running from a scheduler my playbook to ensure that the servers are always in correct setup. But that doesn't account for unexpected changes in the server.

I prefer that the ansible doesn't run, or doesn't allow some actions up front, than to fight for hours/days/weeks to find out what is wrong with the server and learn that a user ran a ansible script with another philosophy on my servers.

So to have a way to allow or disallow what the user can do with their Ansible seems sound to me, especially if there is NOT one person running these scripts on a server but you can have several people using them, and not all of them with the same philosophy.

When Ansible was a niche project, that was nice. But now everybody wants to use ansible, which is great... but now we need a clear way to have permissions. limiting with SUDO is a way, but maybe we could have something like Ansible ACL. I don't care what solution, but a solution needs to be found or invented.

And just saying "constrained use of sudo isn't how Ansible works" is just irresponsible for the sys admin that needs to have a sound/secure environment.
And yes, it will probably make Ansible less "light"...

[klauern]

One of the things I did to get around this was to develop a sudo_action module that used Python's subprocess module to pass the sudo command + enter the password. I doubt it's portable, but it works for my RHEL6 servers for the time being.