Debian – Fix broken permissions on /var (or any other system directory)

debianpermissionssystem-recovery

Long story short, I destroyed /var and restored it from backup – but the backup didn't have correct permissions set, and now everything in /var is owned by root. This seems to make a few programs unhappy.

I've since fixed apt failing fopen on /var/cache/man as advised here as well as apache2 failing to start (by giving ownership of /var/lib/apache2 to www-data). However, right now the only way to fix everything seems to be to manually muck around with permissions as problems arise – this seems very difficult as I would have to wait for a program to start giving problems, establish that the problem is related to permissions of some files in /var and then set them right myself.

Is there an easy way to correct this? I already tried reinstalling (plain aptitude reinstall x) every package that was listed in dpkg -S /var, but that didn't work.

Best Answer

Actually apt-get --reinstall install package should work, with files at least:

➜  ~  ls -l /usr/share/lintian/checks/version-substvars.desc        
-rw-r--r-- 1 root root 2441 Jun 22 14:19 /usr/share/lintian/checks/version-substvars.desc
➜  ~  sudo chmod +x /usr/share/lintian/checks/version-substvars.desc
➜  ~  ls -l /usr/share/lintian/checks/version-substvars.desc        
-rwxr-xr-x 1 root root 2441 Jun 22 14:19 /usr/share/lintian/checks/version-substvars.desc
➜  ~  sudo apt-get --reinstall install lintian  
(Reading database ... 291736 files and directories currently installed.)
Preparing to unpack .../lintian_2.5.27_all.deb ...
Unpacking lintian (2.5.27) over (2.5.27) ...
Processing triggers for man-db (2.6.7.1-1) ...
Setting up lintian (2.5.27) ...
➜  ~  ls -l /usr/share/lintian/checks/version-substvars.desc
-rw-r--r-- 1 root root 2441 Jun 22 14:19 /usr/share/lintian/checks/version-substvars.desc

Now, you probably didn't get all the packages that have files on your /var directory, so its better to find them all:

➜  ~ find /var -exec dpkg -S {} + 2> /dev/null | grep -v "no path found" | wc -l 
460

In my case, it accounts for 460 paths that have a package, this is actually less if you consider that the same package can have several paths, which with some post processing we can find out that are ~122:

➜  ~  find /var -exec dpkg -S {} + 2> /dev/null | grep -v "no path found" | cut -d : -f 1 | sort | uniq | wc -l
122

This of course counts several package that has the same path, like wamerican, aspell-en, ispanish, wspanish, aspell-es, myspell-es. This is easily fixable:

➜  ~  find /var -exec dpkg -S {} + 2> /dev/null | grep -v "no path found" | cut -d : -f 1 | sed 's/, /\n/g' | sort | uniq | wc -l
107

So, I have 107 package that have any kind of file in /var or subdirectories. You can reinstall them using:

sudo apt-get --reinstall install $(find /var -exec dpkg -S {} + 2> /dev/null | grep -v "no path found" | cut -d : -f 1 | sed 's/, /\n/g')

This should fix the permissions.

Now, there's another option, find a good installation and copy the file permissions over your installation with:

chmod --recursive --reference good/var bad/var

Related Solutions

System Recovery – Fixing a Broken System After ‘chmod -R 644 /’

The good news is that all your data is still there. The mixed news is that your system installation may or may not be recoverable — it depends where chmod stopped.

You will need to boot into a rescue system to repair it. From the rescue system, mount your broken installation somewhere, say /mnt. Issue the following commands:

chmod 755 /mnt
find /mnt -type d -perm 644 >/mnt/bad-permissions
find /mnt -type d -exec chmod 755 {} +

The first find command saves a record of directories with bad permissions into a file. The purpose is to see where permissions have been modified. The second find command changes all directories to be publicly accessible.

You now have a system where all directories listed in /mnt/bad-permissions and all files in these directories are world-readable. Furthermore files in these directories are not executable. Depending on which files were affected, this may be easily repairable or not. See Wrongly set chmod / 777. Problems? for what you can try to get the system functional, to which you should add

chmod a+x /bin/* /sbin/* /usr/bin/* /usr/sbin/* /lib*/ld-*

But even if you manage to get something working, there's a high risk that some permissions are still wrong, so I recommend reinstalling a new system, then restoring your data. How do I replicate installed package selections from one Debian system to another? (Debian Wheezy) should help.

Ny standard on the permissions for system directories

All else being default, 0550 and 0700 have no practical differences for /root: the directory has group "root" so the group permissions make no difference, and whether or not the "root" user is given write permission is moot, because he's root anyway.

The difference between 2775 and 0775 for /usr/local also does not usually make a difference: the sticky bit for directories ensures that only the creator of files may delete them, but the default permissions only allow user "root" to create files anyway, who is also the only user given permission to delete them. The sticky bit would become relevant if you allow a non-root user to create files or subdirectories in there.

Therefore, these two choices only represent different philosophies and don't usually offer any practical differences.

I'm sorry that I haven't been able to point to relevant standards here, except to say I don't think there are any. How you set up your file permissions is up to you, the system administrator, and distributions just have their own way of doing it for you that balance security and usefulness.

Best Answer

Related Solutions

System Recovery – Fixing a Broken System After ‘chmod -R 644 /’

Ny standard on the permissions for system directories

Related Question