Recovering from bad chown command

I was going to change the ownership of a directory to apache:apache, but I ended up running:

chown -R apache:apache /

Bad! Very bad! I knew what was going on when it started saying:

chown: changing ownership of `/proc/2694/fd/48': Permission denied

That's when I stopped everything (Ctrl+C).

The current system I have is a server running virtualbox running CentOS 5. This problem happened inside the VM.

Currently, everything seems to be working, but I have not restarted the system yet, and to be honest, I'm afraid that if I did something will break.

I do not know chown's order, should I be concerned and assume something will break after a reboot? Is there a way to recover form this problem without having to rely on backups? I do have a daily one, but I thought there may be a simpler way out.

Solution 1:

It would be good to have an old backup, but IMHO it would suffice to be able to extract the ownership data.

I would it do this way:

• First, make a backup of the current state.

• Then, restore the original properties according to the RPMDB. This will probably repair a lot of your files

• To identify and repair the remaining ones, find all files which are still subject to this problem. These are the files which belong to apache:apache and are in the "search order" before /proc . Maybe you do

  ls -U /
  

  first and get the list of root level entries before /proc (I suppose this is where you canceled the process).

  Then do a

  find /foo /bar /baz -user apache -group apache
  

  replacing foo, bar, baz with the entries identified before. Redirect find's output to a file.

• Extract all the ownership data of the given files from the backup and apply them to the files.

Solution 2:

rpm --setugids will restore ownership for the packages passed to it. Pass -a to restore all packages. You may also need --setperms to restore setuid/setgid permissions.

Solution 3:

In all honesty it's easiest to schedule a proper restore from your last backup at this point. Fortunately you can still do another, final, backup to preserve your current user data; then restore your old backup, and finally restore your user/customer data from your final backup, making sure you preserve the permissions of each group of files as you do so.