FAILED => Missing sudo password when NO SUDO PASSWORD is needed

I have SUDO configured to work without passwords.

This command works just fine:
ansible quee -a “/usr/bin/sudo /usr/bin/apt-get update”

This command fails with "FAILED => Missing sudo password "
ansible quee -a “/usr/bin/apt-get update” --sudo

It works if I add --ask-sudo-pass and enter a sudo password.

I am using Ansible 1.7.2 on Debian Jessie (current stable)

I want to use Ansible playbooks and expect that I will need --sudo to work properly without passwords.

Have I missed something obvious?

Any help much appreciated.

I’ve found the answer elsewhere on the list - Ansible SUDO is not the SUDO you expect.

Basically Ansible SUDO executes a temporary scrip on the fly - something like:

ssh ‘/bin/sh -c “sudo /tmp/ansible-temp-script”’

A better approach would have been to place the SUDO command INSIDE the temporary script around each command.

This would enable fine-grained SUDO configuration on each of the managed hosts.

I assume that the problem is in passing the password through to each command for those that want passwords.

Personally I would be happy with a SUDO_COMMAND option that only works for password-less sudo permissioned commands.

You can work around the SUDO issues by setting the SUDO permissions and then writing your own modules etc that use SUDO commands, e.g.

  • command: /usr/bin/sudo /user/bin/apt-get update

  • command: /usr/bin/sudo /user/bin/apt-get upgrade -y

Or you can follow the Ansible recommendations - which effectively give root access to any command, using your password.

You are making the assumption that all modules shell out to run
commands, this is true only for a few modules. Most modules use
functions native to the language they are written in (python in the
case of those shipped with ansible, but it can be any scripting
language) which would end up calling the same system calls most
command line utilities use but that would not allow for fine grain
sudo to match.

Is that really true of most modules? AFAIK things like apt-get are not available via a system call.

Security is a big concern and it seems that Ansible is designed to require SUDO anything, which kind of defeats the purpose of SUDO in the first place.

And trying to get Ansible to work with password-less SUDO?

Allowing root access to any command with no password, somehow feels like we have increased the size of the attack surface somewhat.

If its impossible to support SUDO properly, why not make the Ansible SUDO something predictable so that it can be explicitly permissioned? At least in that scenario, Ansible is taking some responsibility.

Are you using unpredictable temp-script names in the hope that this is more secure, or to prevent multiple-executions from colliding?

Is that really true of most modules? AFAIK things like apt-get are not
available via a system call.

In the case of apt, it uses the python apt library which talks
directly to the apt bindings, it does shell out for some commands but
not all.
But take 'file' for example, it sets file permissions using the python
builtins which will not call 'chmod' command line.

Security is a big concern and it seems that Ansible is designed to require
SUDO anything, which kind of defeats the purpose of SUDO in the first place.

No, sudo is still there to control who can execute as which user,
ansible also supports SU. What you do loose is fine grained
permissions, which is one reason people use SUDO over SU.

And trying to get Ansible to work with password-less SUDO?

That is up to you, Ansible can use it with or without passwords as
different environments have different requirements and setups.

Allowing root access to any command with no password, somehow feels like we
have increased the size of the attack surface somewhat.

again, not a requirement, that is up to your setup.

If its impossible to support SUDO properly, why not make the Ansible SUDO
something predictable so that it can be explicitly permissioned? At least in
that scenario, Ansible is taking some responsibility.

Hard to do when you don't install anything on the machine, this is a
tradeoff for not having an agent, you could install ansible-pull on
the machines and use it to execute everything running as root from
cron (this is how most agent manage machines, by being root in the
first place).

Ansible can be mostly predicted by using the remote_tmp to control
where the scripts are put, there are issues like when sudoing to a non
root user in which this is switched to /tmp to allow both users access
(root does not normally have this problem unless NFS or something like
that is involved).

With pipelining we don't even copy the scripts to a location but
execute directly over ssh as a pipe, this prevents secrets from ever
being written to disk, but makes sudoers settings that much harder.

Are you using unpredictable temp-script names in the hope that this is more
secure, or to prevent multiple-executions from colliding?

mostly to avoid collisions, but it does help a bit to make it harder
for others to predict the script locations and drop in their own.

I’ve used sudo for different tasks in my play so I can get more granularity that way. You can say “sudo: true” or “sudo:false” in a task within a playbook that has sudo set to either true or false.

EG

  • name: compile thingy
    command: make thingy
    sudo: false
  • name: install thingy
    command: make install
    sudo: true

Holy Cow! Apparently sudo is uncool and now it’s all “become”. See this link for details. Totally new to me!
http://docs.ansible.com/ansible/become.html

On Tuesday, November 10, 2015 at 8:48:53 AM UTC-8, Jeff wrote:http://docs.ansible.com/ansible/become.html

Oh, another important thing about sudo! Don’t use wildcards in a sudoers file if you care about the args your user passes! You cannot specify how many args are allowed, so no matter how tightly you construct the wildcard, the user can always add more args. Either use literal commands in the sudoers file or use a wrapper that sanitizes the args and have sudo call the wrapper.