cannot open `/etc/sudoers' for reading

368 views
Skip to first unread message

Makimoto Marakatti

unread,
Apr 8, 2014, 6:13:30 AM4/8/14
to ansible...@googlegroups.com
Hi all

I'm having a weird issue that I can't figure out:

I'm making a backup of /etc/sudoers from client boxes, before templating.
ansible complains it has no rights to read /etc/sudoers. (with sudo)
And yet it can read any other file in /etc/.
/etc/sudoers has 0440 as permissions.

I've tried with fetch, shell, command, and lastly script.
All fail with some variation of this:

failed: [clientbox] => {"changed": true, "rc": 1}
stdout
: cp: cannot open `/etc/sudoers' for reading: Permission denied

And I know this is not a permissions issue as this actually works in the same box:

ssh -t clientbox "sudo -Hi cp /etc/sudoers /tmp/temp_sudoers && sudo -Hi chmod 777 /tmp/temp_sudoers && scp /tmp/temp_sudoers ansible_masterbox:/tmp/"

Could anyone please let me know what I'm doing wrong here?

Thanks

James Cammarata

unread,
Apr 8, 2014, 10:21:01 AM4/8/14
to ansible...@googlegroups.com
Do you have selinux enforcing?


--
You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-proje...@googlegroups.com.
To post to this group, send email to ansible...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/eee2d34a-a2e5-408d-8ccc-e67c11d5a7ee%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Makimoto Marakatti

unread,
Apr 8, 2014, 10:33:50 AM4/8/14
to ansible...@googlegroups.com, jcamm...@ansible.com
[root@clientbox tmp]# sestatus
SELinux status:                 disabled

Same result in both client and master.
So I have been doing tests and I cannot read any file which is set 0440 owned by root, through ansible.

[root@clientbox tmp]# stat /etc/sudoers
 
File: `/etc/sudoers'
  Size: 10092           Blocks: 24         IO Block: 4096   regular file
Device: fd00h/64768d    Inode: 1246098     Links: 1
Access: (0440/-r--r-----)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2014-04-08 13:55:52.000000000 +0100
Modify: 2014-04-08 12:59:46.000000000 +0100
Change: 2014-04-08 12:59:46.000000000 +0100


But I can do whatever I want through ssh, sudo and a pseudo tty.
As it should be...

And of course this is a issue *I* have. I still remember the cake of JP Mens.
But still ansible does not play ball and straight ssh does.

Any help appreciated.

James Cammarata

unread,
Apr 8, 2014, 11:02:53 AM4/8/14
to Makimoto Marakatti, ansible...@googlegroups.com
I was curious because ansible is actually executing the commands through python, so I wanted to be sure that no selinux rule was preventing that on your system.

Could you also please share the playbook you're running (only the failing step is required) as well as the output run with -vvvv? 

Thanks!

Petr Sukharev

unread,
Apr 8, 2014, 1:01:48 PM4/8/14
to ansible...@googlegroups.com

Do you try to copy files via single command, like ansible -i hosts all -m shell -a 'cp /etc/sudoers /tmp/temp_sudoers' or via playbook?

Any example?...

Makimoto Marakatti

unread,
Apr 9, 2014, 4:26:06 AM4/9/14
to ansible...@googlegroups.com
Hi

James: This is one of the playbooks I've tried:

---
- hosts: clientbox
  gather_facts
: no
  tasks
:
   
- name: cp sudoers from /etc to /tmp
      command
: /bin/cp /etc/sudoers /tmp/cpsudoers

   
- name: change permissions of /tmp/sudoers
      file
: src=/tmp/cpsudoers mode=0777

   
- name: fetch sudoers
      fetch
: src=/tmp/cpsudoers dest=/ansible/deployment/files/backup/sap/sap-t

   
- name: rm /tmp/sudoers
      command
: removes=/tmp/cpsudoers

And this is the result:

$ ap ~/deployment/playbooks/fetch_files_from_server.yml -Kvvvv
sudo password
:

PLAY
[clientbox] ******************************************************************

TASK
: [cp sudoers from /etc to /tmp] ******************************************
<clientbox> ESTABLISH CONNECTION FOR USER: ansible
<clientbox> REMOTE_MODULE command /bin/cp /etc/sudoers /tmp/cpsudoers
<clientbox> EXEC ['ssh', '-C', '-vvv', '-o', 'PasswordAuthentication=no', '-o', 'ControlMaster=auto', '-o', 'ControlPath=~/tmp/ansible-ssh-%h-%p-%r', '-o', 'Port=22', '-o', 'KbdInteractiveAuthentication=no', '-o', 'PreferredAuthentications=gssapi-with-mic,gssapi-keyex,hostbased,publickey', '-o', 'PasswordAuthentication=no', '-o', 'ConnectTimeout=30', 'clientbox', '/bin/bash -c /usr/bin/python']
EXEC previous known host file
not found for clientbox
failed
: [clientbox] => {"changed": true, "cmd": ["/bin/cp", "/etc/sudoers", "/tmp/cpsudoers"], "delta": "0:00:00.005682", "end": "2014-04-09 08:57:11.603329", "rc": 1, "start": "2014-04-09 08:57:11.597647"}
stderr
: /bin/cp: cannot open `/etc/sudoers' for reading: Permission denied

FATAL: all hosts have already failed -- aborting

PLAY RECAP ********************************************************************
           to retry, use: --limit @/ansible/fetch_files_from_server.retry

clientbox                      : ok=0    changed=0    unreachable=0    failed=1

Petr: I get the same result as an ad-hoc command:

$ a -m fetch -a "src=/etc/sudoers dest=/ansible/deployment/files/backup/sap/sap-t" clientbox -K
sudo password
:
clientbox
| success >> {
   
"changed": false,
   
"file": "/etc/sudoers",
   
"msg": "no read permission on remote file, not transferring, ignored"
}

But of course, the twist is, that this actually works:

$ ssh -t clientbox "sudo -Hi cp /etc/sudoers /tmp/temp_sudoers && sudo -Hi chmod 777 /tmp/temp_sudoers && scp
/tmp/temp_sudoers ansible-masterbox:/tmp/"

Please enter the password for user ansible:
ansible@ansible
-masterbox's password:
temp_sudoers                                                            100%   10KB   9.9KB/s   00:00
Connection to clientbox closed.

$ ll /tmp/*sudo*
-rwxr-xr-x 1 ansible ansible 10092 Apr  9 09:11 /tmp/temp_sudoers*

And in theory it is the very same logic. Ansible actually uses "sudo -Hi" to log in to the boxes.

Thanks both for the time.
Any insights into this, greatly appreciated.

Petr Sukharev

unread,
Apr 9, 2014, 12:30:38 PM4/9/14
to ansible...@googlegroups.com


And in theory it is the very same logic. Ansible actually uses "sudo -Hi" to log in to the boxes.


Are you sure?
Try to add  "sudo: True" in your exanple playbook.

Adam Morris

unread,
Apr 9, 2014, 2:57:35 PM4/9/14
to ansible...@googlegroups.com
or -s on the command line.  Just because you have it asking for your Sudo password doesn't mean that it's using sudo (I've run into that myself before).

Adam 

Makimoto Marakatti

unread,
Apr 10, 2014, 4:16:56 AM4/10/14
to ansible...@googlegroups.com
Petr, Adam, you are both right.
I't amazing how you don't see the trees because of the forest sometimes.
Thanks both.
Very much solved.
Reply all
Reply to author
Forward
0 new messages