Changed the mode of /var on debian

Question

I ran chmod 777 recursively on /var/ and could no longer connect via SSH. I read that chmod 600 would fix it. I was able to connect after doing it but this was a bad idea.

Is there anyway I can find the default modes for the folders in /var/ or how to fix this?

Running on Debian-Squeeze.

Answer 1

This is a very common error for people coming from an OS that lack the permission concept. Many

sudo chmod -R 777 /

and such have been issued with perhaps good intentions, but it is also more or less the one user error that could make me recommend "just reinstall" for a *nix system.

If you just chmod -R 755, then you will among other things give read and execution permission to every file for anyone. If one just removes execution for every file (directories need it to be browsable), then one will remove the execution bit for some files that were supposed to be executable, and so on.

In this case it is perhaps not as severe as -R /, but in e.g. /var/log there are many files that are not supposed to have read permissions for anyone. A small excerpt:

-rw-r--r-- alternatives.log
drwxr-x--- apache2
drwxr-xr-x apt
-rw-r--r-- aptitude
-rw-r----- auth.log
-rw-r----- boot
-rw-rw---- btmp
drwxr-xr-x ConsoleKit
drwxr-xr-x cups
-rw-r----- daemon.log
drwxr-xr-x dbconfig-common
-rw-r----- debug
-rw-r----- dmesg
-rw-r--r-- dpkg.log
-rw-r--r-- duplicity-backup.0
drwxr-s--- exim4
-rw-r----- fail2ban.log
-rw-r--r-- faillog
-rw-r--r-- fontconfig.log
drwxr-xr-x fsck
drwxr-xr-x hp
drwxr-xr-x installer
-rw-r----- kern.log
-rw-rw-r-- lastlog
-rw-r--r-- lpr.log
-rw-r--r-- mail.err
-rw-r--r-- mail.info
-rw-r--r-- mail.log
-rw-r--r-- mail.warn
-rw-r----- messages
drwxr-x--- mrtg
drwxr-s--- mysql
-rw-r----- mysql.err
-rw-r----- mysql.log
drwxr-sr-x news
-rw-r--r-- popularity-contest
-rw-r--r-- pycentral.log
-rw-r--r-- rssdler.log
drwxr-xr-x samba
-rw-r----- shorewall-init.log
-rw-r----- syslog
drwxr-xr-x unattended-upgrades
-rw-r----- user.log
-rw-rw-r-- wtmp
-rw-r--r-- Xorg.0.log

This is not trivial to restore. And that was just one directory.

All in all: even if you did make SSH work again, you have had some not trivially repairable permission information loss. If it concerns a strictly personal server, the consequences are probably not that dire, but the permissions are set as restrictive as possible for a reason. In e.g. the log files I mentioned above, sensitive information may be stored, and now it is enough for an exploit with gives regular user rights to find this out and gain even more information for root permission attacks.

---

I last saw someone give the "Do chmod -R 777!!!" tip yesterday on a local forum. Don't trust the internet! :-)