4

Cause of the problem

I intended to add group write permission on hidden files like '.hgignore' with the following:

# pwd
/opt
# sudo chmod -R g+w .*

The problem is that '..' matched this pattern, and now the entire RHEL filesystem has g+w set. The immediate problems are the following:

  • /etc/sudoers needs to be set to 440, not 460, so now users cannot use sudo.
  • Some similar mechanism to the above doesn't allow ssh access. (Remote ssh clients receive the message "ssh_exchange_identification: Connection closed by remote host" error)

Question

In order to regain the ability to log in remotely, someone with physical access to the server needs to be instructed on how to fix the system.

The question now is: what important files and directories need to have their permission reverted in order to restore ssh and sudo functionality?

Note about "closed as duplicate"

The question Why is "chmod -R 777 /" destructive? provides detailed explanations on what effect recursively expanding permissions can have. This question is intended to answer to question of how to regain remote access via ssh so that more extensive restoration and repairs can be performed.

6
  • In what format do you keep your backups?
    – chris
    Jul 14, 2009 at 0:09
  • @FalconMomot This question is not even remotely a duplicate. The questioner does not want to know whether that was a good idea, he wants a solution for the problem. The other thread does not offer that in any way. Jun 2, 2013 at 14:39
  • The answers are the same. It's destructive, so your choices are basically to restore from backup or attempt to find and fix everything that needs it. I see this question a lot. Jun 2, 2013 at 19:57
  • @FalconMomot I've changed the question to clearly state the need to restore remote access as well as the ability to sudo in order to further restore the system. The other question, as HaukeLaging stated, does not offer an answer to this question. Jun 4, 2013 at 15:41
  • 1
    You reinstall, or restore from backup. Jun 4, 2013 at 15:52

4 Answers 4

5

For files that are part of a package, you can find out what was messed up by doing

rpm --verify "packagename"

where packagename is an individual package, or you can loop through the output of "rpm -qa"

Then you should be able to use rpm to fix them with something like

rpm --setperm "packagename"

4

The issue with ssh is most not limited to just under /etc and also has to do with the .ssh folder of the user you are trying to connect with having improper permissions. Generally the .ssh folder for a user should be 700, private keys should be 600, and everything else can be 644.

The /etc/ssh folder should be 755, under /etc/ssh the private keys should be 600, and everything else should be 644.

Howto recover a server from bad permissions in /etc?

Possibly one of the easiest methods might be to restore from your backup. You do make backups and have tested the restore procedures right? :)

If you don't have a backup that you can use to do a restore from, you may need setup a clean system that is identical in a VM and then fix the permissions on the host based on your server by comparing the two.

2
  • +1 but what a mess. I hope a backup is available or you will be doing the compare and chmod all night. I don't see a better way right now.
    – egorgry
    Jul 13, 2009 at 18:33
  • 1
    +1 - This is a huge mess. If you can't restore the backup to the production system, consider restoring it to a subdirectory on another system. Write a script (or pay someone else) to grovel thru the restored filesystem and to produce a script to re-apply permissions to the "production" box. Jul 13, 2009 at 18:45
3

If you have a known good server, running something like the following on the good server might help you restore it. (Assumes recursive globbing ability (zsh), could use find with -exec / xargs instead):

for i in /etc/**/*; do
    perm=$(stat "$i" -c "%a")
    ssh root@badServerHostName "chmod $perm $i"
done

Might be a couple sub directories to exclude other might add... Rsync would be better if it could do only permissions, but I don't think it can.

1
  • As an alternative to ssh: You could modify this to create a text file, copy it to the server, and then read the filename and permissions from the textfile on the bad server. Jul 13, 2009 at 19:01
1

If you have a backup and you have LVM and sufficient space you could do the following:

1.restore the backup to a new, temporary lv (mount it under /oldperm)
2. do something like the following pseudocode:

foreach oldfile in /oldperm/* {  
  newf = strip "/oldperm" from oldfile  
  chmod --reference=oldfile newf  
}

You can restore partially, like everything under /etc first, in case you have space issues. This trick relies on chmod's flag --reference that takes as a template another file and makes the argument match in permission-wise.

This way you only restore the old perms without changing the contents of the files.

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