22

If I run:

sudo chown -R user:user /

Can I revert it to what it was before I ran it?

Mat
  • 52,586
fronthem
  • 5,107
  • 2
    Just as a warning to others: The following command sudo chown -R user:user .. could have the same effect as the one mentioned here if you are one level below the root of the file system. Do not attempt something like this. – passerby51 Oct 09 '15 at 05:38

6 Answers6

27

In short: no.

You'll need to restore from a backup. (Some backup tools might have options to only restore permission, others can list backed-up files with their permissions and you can use that to fix your system.)

If you don't have a backup, you'll need to fix all that manually.

ctrl-alt-delor
  • 27,993
Mat
  • 52,586
  • 1
    After sudo chown -R user:user /, it's likely that the system is so badly hosed that you can't restore from a backup. – Keith Thompson Sep 22 '12 at 23:59
  • 3
    If you can't recover the important parts of your user data in this scenario from your backup, your "backup" really isn't one. If you can't recover the whole OS, you should still be able to re-install the base and then restore from backup. Will very likely need a live CD or network boot in this case, but if your backup strategy can't recover from this, it's not really good enough. – Mat Sep 23 '12 at 06:13
  • 2
    My earlier comment was probably unclear. A functioning system can be restored using the system itself. Once you've done the chown described, it's likely that you won't be able to do anything before installing the whole system from scratch; the system doesn't even have a root account, and sudo won't work. It's probably worth trying to boot to a single-user shell, but don't expect it to work. – Keith Thompson Sep 23 '12 at 09:55
  • 3
    The root account isn't gone (it's still UID 0); it just doesn't own any files anymore, but root bypasses normal permission checks anyways. Whether sudo or even su will continue to function when all its relevant files are owned by user is a different matter (probably not because among other things the SUID bit on the exe will be gone). – jw013 Oct 04 '12 at 21:29
8

If your distro is RPM based, you can restore ONLY files that installed by rpm packages.

To restore all package permissions:

rpm --setperms -a

To restore all package owner (user/group):

rpm --setugids -a

If -a doesn't run, you can execute a bash loop:

For permissions:

for x in $(rpm -qa); do rpm --setperms $x; done

For owner:

for x in $(rpm -qa); do rpm --setugids $x; done

Extracted from: http://www.sysadmit.com/2016/10/linux-restaurar-permisos-de-un-paquete.html

Egon Spengler
  • 81
7

Only if you know the user and group ownership of every file and directory under your / directory.

Even then, you've already clobbered the ownership of critical system files that need to be owned by root, including the sudo command. You'd probably need to mount the hard drive on another system -- and be aware that the other system likely won't have the same UID and GID mappings as the one you just clobbered.

Make a copy of the entire hard drive if you can, then reinstall your operating system. Once you've done that, you can try copying files back to the newly wiped system and restoring their ownerships. You can probably assume (though not 100% reliably) that everything under /home/foo is owned by user foo, and that each mail spool file under /var/mail is owned by the appropriate user (if you have e-mail on the system). You can likely get away without restoring most files that aren't under /home, depending on what you've done with the system.

And then start cultivating a habit of double-checking any command you run under sudo before you hit Enter.

Keith Thompson
  • 22,340
3

You can store the current versions and then parse that out to revert by using the -v option. 

chown -R nobody:nobody -v /tmp/some_file > /tmp/chown.log
cat /tmp/chown.log

The contents would be:

changed ownership of `/tmp/some_file' from me:users to nobody:nobody

Using your favorite scripting language and regular expressions, you can execute the painful process of reverting them (if you must).

I'd strongly recommend not doing a recursive chown on / as you'll expose /etc/shadow or any other important file.

SailorCire
  • 2,503
1

if the distro is rpm-based:

rpm -a --setperms
shcherbak
  • 493
  • 2
  • 10
-2

While developing a Laravel Project on Kali Linux, NPM needed accelerated privileges to install a package. It was a /usr/lib permission issue. A few google tabs later, I ran chown -R $USER /usr/lib . Permissions changed and the sudo command could no longer work. How I fixed it? Downloaded a live system image from kali.org burnt on a thumbdrive/flash, booted my livesystem, updated it, and mounted the drive with broken privileges. Escalated the live system to root and changed the permissions thus:

root@kali:/kali:<partitions-alphanumeric-name># chown -R root /usr/lib

I shutdown the live system, and booted into the installed system. sudo worked. I avoided the popularly recommended reinstall.

Giomalik
  • 1