0

[Edit: See full list of commands I ran at the bottom.]

I accidentally ran chmod +x * inside ~/.config which contained two .sh file that I wanted to make executable. There is no prompt for password nor confirmation window in this situation, and I knew it, but that was a moment of inattention and it was already too late when I realized what I just typed.

Turns out that at some point, in a moment of panic, I ran chmod -R 755 * based on the beginning of this answer, as if reacting fast in that moment would make things better. This totally made things worse, spreading the issue to the whole system.

Fortunately, I was not super user (I would probably have thought more carefully if I had been, maybe I would have avoided the issue in the first place), but the extent of the damage already seems quite massive. All files and folders on my system that my user owned are now executable. This includes pretty much every kind of file, and over 10 TB in total, because I had several HDD mounted in /run/media/.

There are probably some folders of my system that I could fix because I know they contained mostly data that should not be executable, like pictures or videos. But I am mostly concerned about the rest.

Can I chmod -x /home to at least limit the security issue, and then fix just ~/.local/share/applications/*.desktop, or are there some other folders that I should check?

What about other / subfolders that my user might have been able to alter? I'm concerned about folders on the Linux system, and /home, but also the HDDs mounted in /run/media/myself (some of them contained software, not just static files).

Could there be a pattern that could help making a list of files for which execution permission is actually relevant, either by extension or from their content? This would perhaps allow me to chmod -x * to revert the massive change and then review manually the list to restore execution permissions on individuals files that should actually be executed.

I am backing up everything I can as I type, but I am backing up files that have been affected. Is there hope?

[Edit] Note that I have a laptop with the same distribution, same username, and many programs in common. Not everything is the exactly the same, but could I list files that are actually executable across the system on the laptop, and then have a script comparing this list to the other computer? If everything is made non-executable on the other computer with chmod -x *, then maybe the executable files found on the laptop that also occur on the other computer could be made executable automatically? Similar approach here.

[Edit 2] After careful review of the history, here is the list of commands I ran: https://p.teknik.io/Simple/blpKo

Koubak
  • 49
  • 2
  • 4
    If you ran that command in that directory then it would have only given execute permissions to the files and directories located in the top level of that directory. In order for it to have operated on the files and directories located deeper in the directory, you would have had to used the -R switch with chmod and it even if you had done that, it wouldn't have operated on all of the files and directories that you own that are not in that directory. – Nasir Riley Aug 10 '19 at 03:36
  • You are right. I carefully reviewed the history of my commands. Turns out that at some point, in a moment of panic, I ran chmod -R 755 * based on the beginning of this answer, as if reacting fast in that moment would make things better. Fortunately I was still a normal user, not root, but this is likely what spread the issue to all files and subfolder in / that my user could edit. – Koubak Aug 10 '19 at 03:54
  • 2
    Do you mean the "Running chmod -R 777 / as root *will break your system*." part at the beginning of the answer, or the chmod -R 755 /bin /boot /dev /etc/ /home /lib /lib64 ... part at the beginning of the answer? – Michael Homer Aug 10 '19 at 04:39
  • I did not run chmod -R 777 /. However I did run chmod -R 755 * as normal user, I was trying to achieve the same as chmod -R 755 /bin /boot /dev /etc/ /home /lib /lib64… in the answer. Don't ask me why I did not follow it carefully, I was not thinking clear. But anyway that answer turned out to have negative comments, and I thought it might make things worse so I stopped my shenanigans after chmod -R 755 *, started to do backups, and came here to ask. – Koubak Aug 10 '19 at 14:45
  • @MichaelHomer I edited the first post to list all the commands that have been run, for clarification. – Koubak Aug 10 '19 at 15:34
  • Relax. ~/.config contains personal application configuration files for your user, the * shell glob would not have expanded to include "system" files, and even if it did, your user would not have had sufficient privileges to have modified them. Most of the errors you are seeing are likely the result of the second command that you ran (chmod -x *) which removed execute permissions from all the immediate subdirectories of ~/.config (execute permission is required in order from programs to traverse directories) – steeldriver Aug 10 '19 at 15:46
  • @steeldriver I know I am fortunate that these commands were not run as root. I got confused thinking chmod -R 755 * was the same as chmod -R 755 /, hence the dramatic tone above. I'm still surprised that ls -la / shows execution permissions, is that normal?

    I suppose the reason why files have been changed outside of ~/.config is the chmod -R 755 /home I ran just before chmod -R 755 * (cf. pastebin). It altered all /home subfolders. I have a /home/koubak/Media symlink pointing to my HDDs in /run/media/koubak/, which I guess is how the whole issue expanded to there too.

     – Koubak Aug 10 '19 at 17:04
  • 1
    Yes, it is normal (necessary, even) for directories to have execute permission - see for example Execute vs Read bit. How do directory permissions in Linux work? – steeldriver Aug 10 '19 at 19:07
  • @steeldriver Good to know, thanks.

    On a forum, someone recommended that I run find /home -type f -exec chmod -x {} \;, which should change files only, and someone else suggested running chmod -R 750 /home, which will apply to folders as well. The other difference is the former command will remove execute permissions on all files but leave the rest as is, whereas the latter will obviously set rwxr-x--- permissions everywhere.

    What would be best in my case? With the second command I probably won't have to manually add execute permissions to files, but is 750 everywhere in /home safe?

     – Koubak Aug 10 '19 at 23:36
  • Don't make things worse by "fixing" all your home directory, while only the permissions of a subfolder was affected! There may be some script in some personal subfolder which needs execute permission, so don't remove all. Also, some directories like ~/.ssh are not allowed to have read permissions for the group, so don't mess with chmod -R 750. It should be save to do a find ~/.config -type f -exec chmod -x {} \;, though. – Philippos Aug 13 '19 at 06:37
  • Thanks @Philippos. It's true that only /home/koubak was affected since I didn't sudo, but I did run it recursively, so that's a lot of other subfolders down the line. Fixing ~/.config is actually OK because I backed up my dotfiles, but other subfolders that I never browsed but that were used by programs might be more of an issue. I expect many had a fea files that needed execute to run correctly. I'll try to fix that slowly over time. In the mean time, I was wondering if I couldn't actually take advantage of my issue and homogenize my files to 664, and 751 for folders. – Koubak Aug 14 '19 at 22:14

0 Answers0