Wrongly set chmod / 777. Problems?

Question

I was trying to run chmod -R 777 ./ but ended up typing chmod -R 777 / and set 777 on my entire machine. What can go wrong? How can I fix it?

Answer 1

Problems? Yes, lots. Can it be fixed? Sure. Faster than reinstalling? Probably not.

My recommendation is to reinstall. Keep a backup of the existing system, and restore the package list and the contents of files in /etc and /var. For /usr/local, you can probably restore permissions manually. For /home and /srv, you'll have to restore the permissions from backups.

If this is a system with multiple local users, note that making some files world-readable has revealed some things that should have remained confidential.

• Your password list is now compromised: local users have had access to the hashed password list and could try to brute-force them. Notify your users of this.
• All private user data (ssh keys, stored passwords, e-mail, whatever else users might consider confidential) has been exposed to all local users. Notify your users of this.

---

If you really want to try repairing (more of a learning exercise than a practical recovery route), first restore the permissions of a few files. Note that while most files are now too open, a few are missing necessary setuid bits. Here are steps you should take before anything else. Note that this is not an exhaustive list, just an attempt at making the system barely functional.

chmod -R go-w /
chmod 440 /etc/sudoers
chmod 640 /etc/shadow /etc/gshadow
chmod 600 /etc/ssh/*_key /etc/ssh*key   # whichever matches
chmod 710 /etc/ssl/private /etc/cups/ssl
chmod 1777 /tmp /var/tmp /var/lock
chmod 4755 /bin/su /usr/bin/passwd /usr/bin/sudo /usr/bin/sudoedit
chmod 2755 /var/mail /var/spool/mail

Then you'll need to restore all the permissions everywhere. For files under /usr, you can reinstall the packages with one of the following commands, depending on your distribution:

• If you're using Debian, Ubuntu, or another distribution based on APT, you can execute apt-get --reinstall install
• If you're using Arch Linux, you can execute pacman -S $(pacman -Qq --dbpath /newarch/var/lib/pacman) --root /newarch --dbpath /newarch/var/lib/pacman, assuming that you're in a Live CD and your Arch install is mounted at /newarch.

For files under /etc and /var, that won't work, as many of them will be left as they are: you'll have to replicate the permissions on a working installation. For files under /srv and /home, you'll have to restore from backups anyway. As you can see, you might as well reinstall.

Answer 2

You may not notice it at first, but lots of things can and will go wrong. The main problem is that the entire security model for the entire system is broken. It's like having a body without a skin, organs all out in the air. It's bound to get infected because it's not meant to function like that. Even if it seems to work for a few minutes, you need to clean this up.

The best way would actually be to start from scratch. This way will greatly reduce your risk and give you a cleaner result in less time. If you have proper backups, this shouldn't be too trying an experience.

If you do try to clean it up, The primary way would be to tell your distro's packages manager to reinstall EVERYTHING on the system including, overwriting config files. Then use whatever verify system it has to look through them and make sure none of them are flagged as having files with permissions out of the ordinary. Next, work through things like user home directories and reset everything to sane permissions en masse, then work through the few things that should have special permissions (like ssh keys files). Lastly, do a full system find for everything marked as 777 and go through the list (it should be small if you've done the other steps thoroughly) and work through them one by one making sure they should be the way they are.

Answer 3

SOLUTION: I TESTED THIS IN CENTOS

This guy saved my job! (You need to access somehow)

http://www.adminlinux.org/2009/07/how-to-restore-default-system.html

1) To reset uids and gids on files and directories :

for u in $(rpm -qa); do rpm --setugids $u; done

2) To permissions on files and directories

for p in $(rpm -qa); do rpm --setperms $p; done

then change manually permisions to these files:

# ll /etc/ssh/
# chmod 600 /etc/ssh/ssh_host_rsa_key
# chmod 600 /etc/ssh/ssh_host_dsa_key
# service sshd restart

Answer 4

Some security-conscious programs will not start if certain files have too "loose" of permissions. As @ceving said, sshd is the most typical of this.

The main thing that can go wrong is now any user can open, read, and write any file on your system. The two reasons why this are bad is: A) if a malicious user gains control of your system either through a an exploit or misconfiguration, he/she can modify anything on your system now, and B) you can delete anything you want even if you are not root, so you've just negated most of the protections of not running as root.

If you didn't back up the permissions beforehand you're in a bit of situation. You might be able to create a script that "fetches" a list of permissions from a freshly installed system and then "apply" those to everything on your system. I don't have such a script handy, though.