Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

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?

share|improve this question
    
    
what can go wrong in the system? will it cease to work? –  Vinnycx May 11 '11 at 15:20
4  
Of course there are problems. SSH will fail for example. –  ceving May 11 '11 at 15:25
1  
SSH exits if the home directory is world readable. Setting everything to 777 is like doing everything as root. –  ceving May 11 '11 at 15:42
2  
See also serverfault.com/questions/364677/why-is-chmod-r-777-destructive which goes into more details as to what will go wrong. –  Gilles Jul 25 '12 at 21:35

3 Answers 3

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.

share|improve this answer
    
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 '11 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. –  ultrasawblade May 11 '11 at 15:32
    
Which applications may cease to work? –  Vinnycx May 11 '11 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 '11 at 15:47
5  
@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 '11 at 17:52

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.

share|improve this answer
    
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 '11 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 '11 at 15:32
    
cron will cease to work just because of 777? –  Vinnycx May 11 '11 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 '11 at 17:54
1  
+1 to "really, just reinstall", by the way. –  mattdm May 12 '11 at 2:03

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.

share|improve this answer
3  
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. –  Arrowmaster May 11 '11 at 23:00
2  
If there are users on the system, I pity them. –  Jürgen A. Erhard May 11 '11 at 23:36

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.