"chown -R root /" how screwed am I?

Question

I accidentally performed the command chown -R root / while trying to change the permissions to the public folder of my rails app. I believed this changed the permissions to all my folders on the / directory. So my question is, how dangerous is this, in fact the better question would be, is there anyway to undo this?

Solution 1

One way to mitigate the issue here (not resolve, but help you out of a hole) is to run a process on a similar system to collect the appropriate ownerships for the files. I appreciate the chances of an exact match are somewhat slim, but if both the o/s's are at the same level with similar packages installed you might be lucky.

Once you have collected the file permissions into a file, you could then run a process on your own system to read the files and perms/ownerships from the good one and replace them on yours. I have a couple of small home-grown apps on Linux that do just this.

E.g.

777*0*0*S*16*1334559119*1334532895*1361208513*/usr/lib32/*libgomp.so.1
644*0*0*F*67370*1359536382*1359374461*1359717843*/usr/lib32/*librt.a
644*0*0*F*59044*1334559119*1334532931*1355405098*/usr/lib32/*libgomp.so.1.0.0
644*0*0*F*1238*1359536382*1359374461*1359717843*/usr/lib32/*libBrokenLocale.a
777*0*0*S*17*1359536382*1359374460*1361208513*/usr/lib32/*libdl.so
644*0*0*F*905712*1334559116*1334533011*1355405098*/usr/lib32/*libstdc++.so.6.0.16
777*0*0*S*15*1333306601*1323929512*1361208513*/usr/lib32/*libbz2.so.1.0
777*0*0*S*24*1359536382*1359374460*1361208513*/usr/lib32/*libnss_files.so
644*0*0*F*1128*1359536382*1359374462*1359717843*/usr/lib32/*crt1.o

RWX * UID * GID * other stuff * directory * filename

Solution 2

First of all, stop the command if it is still running!

Now everything will belong to root and that is quite problematic.

You should try to restore information from your latest backup.

It is also important not to restart the system before checking all the applications running and the user launching them on boot. If you do, some of them may not start properly due to permissions problems.

Good luck.

Solution 3

Very and not quite.

"Very" in the sense that if the command has indeed gone through, your security is screwed. You now do not know which paths have what owners and who should be allowed to do what.

"Not quite" in the sense -- are you sure you were root when you did it and did the command go through to the end? If you've cancelled it, as soon as you saw it, then you might be lucky and the repair may be low. If you weren't root, this command shouldn't have been able to do it, unless you did something like sudo ....

There is no single remedy to this. If you have a backup, you can restore to it. You might need to check the ownerships in the backup and apply them. If you have been using a rootkit (say rkhunter) checker, it might have a list of the most basic ownerships and possibly be able to fix it. (Not quite likely).

Solution 4

On Fedora at least, the RPM command has the options --setperms and --setugids, using those you can fix most of the system owned files like rpm --setugids -a. To (somewhat) fix the files for each user, you can do for each one chown -R user /home/user. There probably will be leftovers that haven't been fixed by the above, particularly if you have some sort of server (web, ftp, others), those will have to be handled one by one.

Probably other distributions have similar mechanisms. Or do a full refresh (i.e., install everything anew, like it was somehow damaged. OK, it was somehow damaged.)

[Yes, this is yet again Unix' rather cruel way of teaching unsuspecting users to consider each command carefully before pressing ENTER, and to use root sparingly. Consider yourself taught.]

Solution 5

If your using OSX apple provides a restore feature within Disk Utilities to fix this very problem. If your using a linux distro, I'm fairly certain you'll have to redo all permissions manually. In either case, smack your hands and don't do it again

View more solutions

Comments

[Chris Kuehl]

It's probably unlikely to be able to recover fully from this on Linux. Even if you can get the system working, you probably missed something that may come back to bite you later, either as instability or a security vulnerability. I would say that a restore from backup or rebuild approach is probably necessary.

[jnas]

setuid and setgid permissions need to be set by hand. rpm won't restore them.