2

I just made a terrible mistake, I tried to fix it by myself but I need some help.

Due to a syntax error all files and folders permissions were being changed: thankfully I saw this while it was happenning and successfully stopped it. "Only" /bin, /boot, and /dev are affected. Here is an excerpt of what happened (full log: http://pastebin.com/4BkbXEqD):

Apr 11 21:34:08 *** sftp-server[20582]: set "/.newrelic" mode 40754
Apr 11 21:34:08 *** sftp-server[20582]: set "/bin" mode 40554
Apr 11 21:34:09 *** sftp-server[20582]: set "/boot" mode 40554
Apr 11 21:34:09 *** sftp-server[20582]: set "/cgroup" mode 40754
Apr 11 21:34:09 *** sftp-server[20582]: set "/dev" mode 40754
Apr 11 21:34:09 *** sftp-server[20582]: opendir "/.newrelic"
Apr 11 21:34:09 *** sftp-server[20582]: closedir "/.newrelic"
Apr 11 21:34:09 *** sftp-server[20582]: opendir "/.newrelic"
Apr 11 21:34:10 *** sftp-server[20582]: closedir "/.newrelic"
Apr 11 21:34:10 *** sftp-server[20582]: opendir "/"
Apr 11 21:34:10 *** sftp-server[20582]: closedir "/"
Apr 11 21:34:10 *** sftp-server[20582]: opendir "/bin"
Apr 11 21:34:10 *** sftp-server[20582]: closedir "/bin"
Apr 11 21:34:10 *** sftp-server[20582]: set "/bin/mknod" mode 100754
Apr 11 21:34:10 *** sftp-server[20582]: set "/bin/cat" mode 100754
Apr 11 21:34:10 *** sftp-server[20582]: set "/bin/ping6" mode 100754

For instance, MySQL is not running anymore, and I'm afraid more damage has been done.

I've tried to restore read and exec permissions on those folders and files but in fact I don't know in which state they were previously.

How can I revert my system to a working state?

dhag
  • 15,736
  • 4
  • 55
  • 65
flop25
  • 21

2 Answers2

2

You should be able to restore permissions from a root shell, if you manage to start one. You should be able to get a root shell by logging in as root on the console. At this point, depending on your configuration, you may or may not be able to gain root access from an ordinary account with su or sudo, and you probably won't be able to log in under any non-root account.

If the transcript you posted is complete, then you were fortunate enough that the files whose permissions are hardest to restore (/etc and /var) are not affected.

Apr 11 21:34:08 *** sftp-server[20582]: set "/.newrelic" mode 40754
Apr 11 21:34:08 *** sftp-server[20582]: set "/bin" mode 40554
Apr 11 21:34:09 *** sftp-server[20582]: set "/boot" mode 40554
Apr 11 21:34:09 *** sftp-server[20582]: set "/cgroup" mode 40754
Apr 11 21:34:09 *** sftp-server[20582]: set "/dev" mode 40754

40754 (octal notation) means a directory, writable by the owner, executable by the owner and group, and readable by everyone. Only the rightmost three digits indicate the permissions, the previous digits encode the file type and cannot be changed. Since the “execute” permission on a directory actually means the permission to access files in that directory, files in these directories can no longer be accessed by most users. Most toplevel directories should have the permission 755, meaning readable and executable by everyone and writable only by the owner (the exceptions are /lost+found which is normally 700, /tmp which must be 1777, and special filesystems like /proc or /sys may not be writable by their owner). I don't know what /.newrelic is, it isn't a standard toplevel directory.

chmod 755 /bin /boot /cgroup /dev

Apr 11 21:34:10 *** sftp-server[20582]: set "/bin/mknod" mode 100754
…

Most files in /bin and /sbin should be readable and executable by everyone, and writable only by their owner. A few of them need to be setuid.

chmod a+x /bin/* /sbin/*
chmod 4755 /bin/su /bin/sudo /bin/mount /bin/umount /bin/ping /bin/ping6
chmod 4754 /bin/fusermount

In /boot, I think all files and directories should be world-readable, and directories should be executable but files should not.

find /boot -type d -exec chmod 755 {} + -type f -exec chmod 644 {} +

This leaves /dev where permissions vary a lot from file to file. Fortunately, /dev is an in-memory filesystem, so the content will be fine after a reboot. If you can and want to restore permissions in /dev without rebooting, I think the following command will do it:

udevadm trigger --sysname-match='*'
Gilles 'SO- stop being evil'
  • 829,060
  • Thank you! In fact it seems that the system was more affected that the log was saying! maybe because of the dev folder , maybe symlinks ... so after crawling and trying I finally saved the server with rpm --setperm – flop25 Apr 17 '15 at 17:55
0

In fact it seems that the system was more affected that the log was saying!
maybe because of the dev folder, maybe symlinks... don't know but after crawling forums etc and trying folder by folder, I finally saved the server with

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

A special thx for @Gilles and his superb answer
A special NO Thx! @dhag for editing my question up to removing my politeness formula

flop25
  • 21