Wrong way to modify linux system file permissions

In order to facilitate the operation, I usually use root login to manage vps. In the face of this supreme authority, a variety of tragedies will occur in case of carelessness. The first two days, originally intended to execute chmod -R 777 ./*, the result is less than one hand slip. Although the command was terminated by pressing ctrl + c in time, the tragedy has taken place.

In the face of rm -rf /, the above misoperation can still be saved. Let's talk about how to restore the correct permissions to the maximum extent. The most important point:

Do not close the current window after executing the command!

Because this time to create a new Terminal, you can't connect to this vps via ssh. Therefore, you first need to fix the relevant permissions of SSH.

To view the correct permissions of SSH-related files on a normal Linux host, do the following:

cd /etcchmod 644 passwd group shadow chmod 400 gshadow

cd Sshchmod 600 moduli ssh_host_dsa_key ssh_host_key ssh_host_rsa_key chmod 644 ssh_config ssh_host_dsa_key.pub ssh_host_key.pub ssh_host_rsa_key.pubchmod 640 sshd_config

Try to log in to SSH and find that it is normal, but you cannot switch to the root account. $ su - rootsu: cannot set groups: Operation not permitted

After checking the relevant information, it is found that su must have s permission to pre-read the relevant configuration of root, so execute the following command to let the owner of su add On s:chmod u+s `which su`

After you finish, you can enter the system as root.

Complete the above steps, just clear the obstacle to enter the system as root, in case the current window is closed, you can not log in again. The permissions for the rest of the files are fixed below.

Find a Linux machine that is as clean as possible, and export the above permissions: getfacl -R /> ./linux.chmod.bak

and then pass the ftp or scp command to the target machine. Top: scp linux.chmod.bak [email protected]:/root/

Import the permissions file on the target machine: setfacl --restore=/root/linux.chmod.bak

After the import is complete, you need to restart the machine to take effect. At this time, the machine basically returned to normal, at least there is no problem in the system function.

In order to be safe, we can write the previous SSH method as a script and then delay execution in rc.local before importing the permissions file. This will solve the problem and need to force a restart, we can also log back through SSH.

Write the contents to /root/tmp.sh: cat /root/tmp.sh

cd /etcchmod 644 passwd group shadow chmod 400 gshadow

cd sshchmod 600 Modili ssh_host_dsa_key ssh_host_key ssh_host_rsa_key chmod 644 ssh_config ssh_host_dsa_key.pub ssh_host_key.pub ssh_host_rsa_key.pubchmod 640 sshd_config

chmod u+s `which su`

Then put the script to boot: echo '/root /sh/sshtmp.sh &' >> /etc/rc.local

Next you can safely import the permissions file and reboot.

If everything is ok after rebooting, remember to remove the script from /etc/rc.local.

Because we imported a list of clean Linux permissions, we just fixed the permissions on the original files of the system. As for the installed program and the files placed on the vps, I haven't thought about how to fix it. Is it only reloading it! ?

Before the lessons of blood, you can't easily use root in the future... (╯‵□′)╯(┻━┻