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?


4 Answers 4


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.

  • 6
    Agreed, unless you are an expert you have almost no chance of repairing this situation without doing a full reinstall or restoring from backups. It is too dangerous to leave the system running as is. May 11, 2011 at 23:00
  • 4
    If there are users on the system, I pity them. May 11, 2011 at 23:36

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.

  • But, aside from security, what can go wrong in terms of applications? Will they cease to work? Or security is the biggest concern here?
    – Vinnycx
    May 11, 2011 at 15:31
  • Security is the biggest concern, but lots of programs, particularly behind the scenes things like logging daemons, cron, etc will fail for various reasons rather than put themselves in the dangerous situation they see.
    – Caleb
    May 11, 2011 at 15:32
  • cron will cease to work just because of 777?
    – Vinnycx
    May 11, 2011 at 15:34
  • 1
    There are several different cron systems, but no self respecting cron should execute jobs in root's cron when the crontab file is world writable! Also the mail daemon that handles cron notifications should complain for other reasons.
    – Caleb
    May 11, 2011 at 17:54


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


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

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.

  • But, aside from security, what can go wrong in terms of applications? Will they cease to work? Or security is the biggest concern here?
    – Vinnycx
    May 11, 2011 at 15:31
  • Just the couple of applications that refuse to start if permissions are too loose. Security is the biggest concern. But it's also system stability. If you do a rm -rf / as your normal user now you'll grind your system to a halt.
    – LawrenceC
    May 11, 2011 at 15:32
  • Which applications may cease to work?
    – Vinnycx
    May 11, 2011 at 15:37
  • Aside from SSH? What else may fail? I need to now if i can leave the system like this for a while.
    – Vinnycx
    May 11, 2011 at 15:47
  • 6
    @Vinnycx: No you can't. It's broken. You should make it a priority to fix it. Otherwise expect your services to fail you one by one and hackers to eat your data. Leaving /*@777 is not an option.
    – Caleb
    May 11, 2011 at 17:52

You must log in to answer this question.

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