Copy file with sudo; sudo /bin/sh not allowed

Hi,

I am sorry for the newbie question, I ve just started looking into Ansible but I did not find any info in the docs or anywhere else that could help me find a resolution.
I have a bunch of hosts on which I have sudo access.
>sudo whoami
root

But I do not have permission to run

> sudo /bin/sh -c echo “Hello!”

Sorry, user some-user is not allowed to execute ‘/bin/sh -c echo Hello world’ as root on blabahost.

This is blocking me from executing a simple playbook which copies files under /etc/yum.repos.d

The playbook like this:

You need unrestricted sudo
https://docs.ansible.com/ansible/latest/user_guide/become.html#can-t-limit-escalation-to-certain-commands

What is the username you are trying to connect as ?

Unfortunately this is not an option for me :confused:

Thanks,
Nicola

You might want to look at using ansible-pull from cron then.

I am running the playbook without specifying an user:

ansible-playbook --ask-become-pass -vvv test-playbook

Running the command with -u flag does not change the error:

ansible-playbook -u napicella --ask-become-pass -vvv test-playbook

where napicella is an user on both the local machine and the remote one

Interesting. Thanks Brian

Well, is that user been given sudo rights on remote machine if so, Could you check if you are able to login as that user and execute the same task manually without ansible.

It does have sudo access, but it is restricted, namely it cannot use exec /bin/sh.
So if I do:
napicella@localhost > ssh blablahost
napicella@blalahost> sudo cp /tmp/a > /etc/yum.repos.d/a

This works as expected, what it does not work is:

napicella@blalahost> sudo /bin/bash -c ‘cp /tmp/a > /etc/yum.repos.d/a’
Sorry user napicella is not allowed to execute /bin/bash …

which appears to be exactly what Ansible does when the become property is set in the playbook task

As @BrianCoca mentioned, I am afraid I need unrestricted sudo access to run Ansible.
From the docs is kinda hard to understand that: https://docs.ansible.com/ansible/latest/user_guide/become.html#can-t-limit-escalation-to-certain-commands
It might be just me, but I do no quite get it

Generally speaking, ansible does not run many shell commands to perform these actions. Instead many modules rely on executing python code that will achieve your goal.

As such, restricting sudo to something like cp can’t work for the copy module.

Instead we run something more like sudo /bin/sh -c '/usr/bin/python /path/to/some/temp/python/script.py'

You can achieve results similar to what you want, by severely restricting yourself to only using the raw/command/shell modules like:

  • command: sudo cp foo bar

It isn’t really recommended to do this, as it doesn’t support password prompting, and you lose a lot of additional functionality provided by the other ansible modules.

Also, let me pose this question, how is allowing sudo cp more secure? I would assume most configurations would allow: sudo cp give_me_access_sudoers /etc/sudoers

I’d recommend talking to the person responsible for your sudoers configuration.

Can you try to change your playbook a little bit.

Just below hosts mention:

remote_user: < username >

remove become_method option ( I assume you are using ansible version => 1.9 )

I don’t think ansible in the backed uses below syntax for any task executions as root:

sudo /bin/bash -c ‘cp /tmp/a > /etc/yum.repos.d/a’

Hi, thanks for the answer.
I agree with u, that using only command is a severe restriction and it kinda miss the point of using Ansible.
As for the question about restricting access, well, great question.

It is more secure, because the sudoers file is generated and kept in sync by a daemon running on the host.
By changing the file, you get unrestricted access for a short time, after which the daemon will override the content.
Stopping the daemon basically cuts the host off from the system.

This is my understanding of how things work, but I am not a system engineer and definitely not an expert.

I tried, same result.
Thanks!

…but I am not sure why restricting shell from sudo is a security measure.
Gotta investigate that.

I think I got it.
Not restricting shell allows for the user to run sudo /bin/sh first and then run whatever the user wants, including sudo su

That is not really a security restraint as `sudo -u` is equivalent to
`sudo su`, agreed that /bin/shell will give you 'unrestricted
commands', but that is normally the requirement if you are going to
manage a server.
41

Right. Thanks for taking the time. Much appreciated!