LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - General (https://www.linuxquestions.org/questions/linux-general-1/)
-   -   Reversal of chown -R oracle . issued from / as root (https://www.linuxquestions.org/questions/linux-general-1/reversal-of-chown-r-oracle-issued-from-as-root-510235/)

ubearcats 12-13-2006 10:04 PM

Reversal of chown -R oracle . issued from / as root
 
Coworker issued chown -R oracle . from / as root. Stopped immediately but damage was already done. This is on CentOS. Wondering if there are any utilities to help reverse this without reinstalling. Any help would be appreciated.

Thanks

frob23 12-13-2006 10:15 PM

Ugh, that's a nasty mess. I don't suppose CentOS uses mtree during the install? It might be a BSD thing, as I know all the BSDs use it.

If you have it, you'll probably have a directory /etc/mtree which will have files with the original information.

If you can get that, if you don't have it already. You will want to use it to make a listing of the correct information for the drive (in case this happens in the future). The program itself can even compare the old permissions and change them back. I hate to have to admit this, but it has saved me once because of a similar mistake.

If you don't have that, you need to find some way to compare a clean filesystem with the messed up one and change the permissions back. This may involve doing a sample install on another system and running a complete listing of all the files to be brought to the new machine and then writing a script to compare owners and fix them if they're different.

Edit: to add some info.

J.W. 12-13-2006 10:36 PM

Quote:

Originally Posted by ubearcats
.... [the] damage was already done...

This is the safe viewpoint. Unless you have an 100% comprehensive and exhaustive listing of each and every file that was incorrectly changed (which I would assume would be unlikely in the extreme) my recommendations would be to:

1. Backup any important data
2. Reinstall
3. Review your security policy, and give only 2 or maybe 3 trusted people true root access. I'm sure your co-worker meant well, but I'd suggest looking at it this way: If his/her actions were a deliberate act, rather than an accident, would you consider it sabotage/vandalism? I would, and I'd consider pressing charges if I knew who was responsible. Maybe it was a true and/or innocent rookie mistake, but even so, I'd only give root to someone whose job actually required it, and they had demonstrated that they would use it responsibly.

Keep in mind that in Linux, it is assumed that root knows what he/she is doing, and thus any commands executed by root will be performed, no questions asked. Good luck with it regardless.

jschiwal 12-13-2006 11:22 PM

You can try using the rpm verify option.

For example, you can verify the /etc/auto.net file with:
rpm -qVf /etc/auto.net
Add the option -v for verbose to verify all of the files that the package supplies:
rpm -qVvf /etc/auto.net

To locate the package the supplies the file enter: rpm -qf <full/file/name>; e.g.:
rpm -qf /etc/auto.net
autofs-4.1.4-23

Now you can look at the default permissions of all of the files that the package supplies:
Code:

rpm -qvl autofs
-rw-r--r--    1 root    root              345 May  2  2006 /etc/auto.master
-rw-r--r--    1 root    root              581 May  2  2006 /etc/auto.misc
-rwxr-xr-x    1 root    root            1272 May  2  2006 /etc/auto.net
-rwxr-xr-x    1 root    root              538 May  2  2006 /etc/auto.smb
-rwxr--r--    1 root    root            9234 May  2  2006 /etc/init.d/autofs
drwxr-xr-x    2 root    root                0 May  2  2006 /usr/lib/autofs
-rwxr-xr-x    1 root    root            11704 May  2  2006 /usr/lib/autofs/autofs-ldap-auto-master
-rwxr-xr-x    1 root    root            13128 May  2  2006 /usr/lib/autofs/showmount
drwxr-xr-x    2 root    root                0 May  2  2006 /usr/lib64/autofs
-rwxr-xr-x    1 root    root            25596 May  2  2006 /usr/lib64/autofs/lookup_file.so

...



All times are GMT -5. The time now is 08:14 PM.