The complete story:

I launched an Amazon EC2 "Tier" (VPS) running RHEL 7.1 and created a key for ssh.

EC2 automaticly crates a user called ec2-user for new Rhel VPSs, and it have the permissions (in sudoers file):

ec2-user    ALL = NOPASSWD: ALL

I crated a new user (with password) called "e" and tried to add him to the sudoers file.

When i tried to edit the /etc/sudoers file with VI, it said the file is read-only, so i changed it's permissions to 600, and now every time i try to do somthing with "sudo" command, i get an error:

sudo: /etc/sudoers is world writable
sudo: no valid sudoers sources found, quitting
sudo: unable to initialize policy plugin

and i can't change it back to 440, becuse i need to be root to do it and i can't do "sudo".

I read somewhere the solution is to run

pkexec chmod 0440 /etc/sudoers

but it asks for password for ec2-user who don't have any password:

==== AUTHENTICATING FOR org.freedesktop.policykit.exec ===
Authentication is needed to run `/usr/bin/chmod' as the super user
Authenticating as: Cloud User (ec2-user)

polkit-agent-helper-1: pam_authenticate failed: Authentication failure
Error executing command as another user: Not authorized

This incident has been reported.

What now? anyone have any idea how to proceed in order to make sudoers file 440 agin?

5 Answers 5


Yeah - that is a "gotcha" for sure. Use visudo in the future to avoid that problem. I have a CentOS 7 VM, which is essentially the same as RHEL7; and I was able to use su - to become root without using sudo, because I know the root password. Do you know your password for the user, root?


Normally, sudo is the only way to elevate permissions on an EC2 instance, because Amazon conveniently provides a user (ec2-user) with sudo rights. Likely few bother to set a password for root, since most use the predefined user. That was the case in this question.

The way to recover this machine would have been to

  • shut the machine down
  • detach its "/" disk from the broken machine (remember which device, probably /dev/sda1)
  • attach that disk to a working machine (this assigns a device)
  • mount the disk on the working machine (using that device)
  • repair the permissions (you have sudo rights on the working machine)
  • umount the disk
  • detach from the working machine and reattach to the broken machine
  • start up the working machine

It helps to have more than one machine, but even if one is needed only for repairs, that can be created, used and deleted within about an hour.

Further reading:


If the instance doesn't contain anything important, I'd suggest chalking this up as a learning experience and blowing it away and starting over. If you must fix it, you could shut down the instance, saving the disk image, and mount it on another instance and fix the permissions.


This worked perfect for me with the following commad:

step 1: run the following command to become root without using sudo or su

pkexec s

step 2: run the following command last command to change a few file permission

chmod 440 /etc/sudoers && chmod 775 /etc/sudoers.d && chmod 440 /etc/sudoers.d/README

step 3: If it works for you please share


if the root user is enabled, use the 'su' command or the 'login root' command to get to the root shell. Then try

chmod 440 /etc/sudoers 
  • AWS has no single-user mode (since EC2 instances can be reached only via ssh). Mar 27, 2016 at 22:49

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .