Accidentally screwed up permissions big time — what should I do?

I’m not very experienced with Linux and I made a big, big mistake. I ran the following command:

chown -R [ftpusername]:[ftpusername] /

I meant to run this:

chown -R [ftpusername]:[ftpusername] ./

See the problem?

I tried to correct my mistake by changing the owner of all files to root:

chown -R root:root /

Now I’m getting permissions errors when trying to access my websites, but my biggest concern is that I want to make sure I haven’t caused any security vulnerabilities here.

Questions:

1. Was changing ownership of everything to root the right thing to do?
2. I think running chown caused some of the folder and file permissions to be changed. Is that normal? Would this cause any security vulnerabilities?

Answers:

Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.

Method 1

Was changing ownership of everything to root the right thing to do?

No. It is, however, the quickest way I can think of to get the system to normal state.

• There are plenty of process which require some directories/files be owned by their user. Examples include logs, caches, working/home directories of some processes like MySQL, LightDM, etc. Especially log files can create a lot of problems.
• There are some applications which are setuid/setgid, and so need their owner/group to be something specific. Examples include /usr/bin/at, /usr/bin/crontab, etc.

I think running chown caused some of the folder and file permissions to be changed. Is that normal?

I doubt modes got changed. If it did, it most definitely is not normal.

Would this cause any security vulnerabilities?

Since you just set /usr/bin/crontab to be owned by root, you now have a setuid application that opens an editor. I doubt any vulnerabilities compare to that. Of course, this is a blatant vulnerability, so something more insidious might now pop up. Overall, I’d recommend simply re-installing the system – or hopefully you have full-disk backups.

Apparently, chown(3) is supposed to clear the setuid and setgid bits if the running process doesn’t have the appropriate privileges. And man 2 chown for Linux says:

When the owner or group of an executable file are changed by an
unprivileged user the S_ISUID and S_ISGID mode bits are cleared.
POSIX does not specify whether this also should happen when root does
the chown(); the Linux behavior depends on the kernel version. In
case of a non-group-executable file (i.e., one for which the S_IXGRP
bit is not set) the S_ISGID bit indicates mandatory locking, and is
not cleared by a chown().

So, it seems the devs and the standards committees have provided safegaurds.

Method 2

Do you have a sister system or a backup? I.e. do you have a system from which you can copy the ownership?

If so: Copy the ownership and find the files that were not in the sister system and set the ownership on those manually.

All methods was sourced from stackoverflow.com or stackexchange.com, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0