4

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?
Nate
  • 241
  • 3
  • 11

2 Answers2

5

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.

muru
  • 69,900
  • 13
  • 192
  • 292
  • on most systems, running chown will clear the suid and sgid bits. – Joshua Jul 06 '15 at 19:22
  • @Joshua how do we know which systems? Any identifying characteristic? – muru Jul 06 '15 at 19:27
  • Every system I've tried has the behavior including HP-UX, Linux, SunOS. If it weren't for the fact that the old SysV specs don't list it I would have been saying all systems. – Joshua Jul 06 '15 at 19:29
  • @Joshua interesting. From [`man 3 chown`](http://manpages.ubuntu.com/manpages/trusty/en/man3/chown.3posix.html): "If the specified file is a regular file, one or more of the S_IXUSR, S_IXGRP, or S_IXOTH bits of the file mode are set, and the process does not have appropriate privileges, the set-user-ID (S_ISUID) and set-group-ID (S_ISGID) bits of the file mode shall be cleared successful return from chown()." (and a couple more lines on clearing suid and sgid bits) Any idea what these `S_IX*` bits are and what the appropriate privileges are? – muru Jul 06 '15 at 19:36
  • Those are the execute bits. The "appropriate privileges" is system specific (there is in fact no requirement that any specific privilege exists at all). – Joshua Jul 06 '15 at 19:46
  • @Joshua updated. – muru Jul 06 '15 at 19:56
0

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.

Ole Tange
  • 33,591
  • 31
  • 102
  • 198