9

WARNING - DO NOT RUN THE MENTIONED COMMAND

So it seems I did something pretty dumb here to put it mildly. I was attempting to change the permissions for a few files in a directory that all started with . to read/write for sudo/root only.

My attempt at changing several files at once seems to have done something pretty horribly global. While inside a directory (wasn't at root dir) I ran sudo chmod 600 .* and well, I'm posting this from my phone now... I still have the terminal window open at the moment, but I'm quite sure if the laptop goes to sleep I'm completely done. Hilariously that means there is a slight urgency to this question.

Oh and this seems to have changed permissions damn near everywhere I'm guessing. I can't even run the ls or cd .. commands. An attempt of cd /home/brian or cd ~ give the error bash: cd: /home/brian: Permission Denied and any attempt at a sudo command just says bash: /usr/bin/sudo: Permission Denied

I am afraid of rebooting, no clue if there is any built in recover from something this dumb, but figured I would try to ask here before making things any worse. I'm a pretty new Linux as my main OS convert and been advocating for it a bit lately, but ouch, this one stings a bit. Any thoughts of things to try would be immensely appreciated.

EDIT: I wanted to provide clarification on how/where this command was executed. This was executed from /.atx $, just an arbitrary directory, but more details below.

While logged in as my regular username brian, I had a terminal open to /.atx that contained three config type text only files. Each filename started with a .. That directory/name/the files aren't any part of a common package, just an arbitrary set of configs I was programmatically moving around. Files contained some SQL server connection string info and just wanted them semi-obscured.

Brian Jorden
  • 231
  • Without description which directory you were in, I'm guessing you were inside /root not / when you did this ( from what I see in your question) which means your .* glob captured /root folder itself ( the . references to current working directory) along with all files/directories that start with leading dot. Not sure if there's a way to change it from your system, but you probably could boot from a live USB and undo things from there. Don't take it as 100% answer, though, just a thought. – Sergiy Kolodyazhnyy Oct 28 '17 at 17:16
  • Appreciate the thoughts and feedback either way and will consider it depending on how things go. This is really just silly.. I'm going to update the main text with details of where I ran the command from (part of why I'm so confused here as it didn't seem dangerous at the time) – Brian Jorden Oct 28 '17 at 17:19
  • 5
    Possible duplicate of What if I accidentally run command "chmod -R" on system directories (/, /etc, ...) – Panther Oct 28 '17 at 17:26
  • 4
    I'm going to make the assumption that the .* in your command expanded to include .., the parent directory of the directory that you were in. If you were in, for example /home/brian then the permissions of /home would have been set to 600 and you would not have permissions to look into the /home directory. Can you in your open terminal execute ls -ld /* – Charles Green Oct 28 '17 at 17:27
  • 2
    You can attempt to restore permission see https://askubuntu.com/questions/43621/what-if-i-accidentally-run-command-chmod-r-on-system-directories-etc . There are several scripts there, but I posted a method using apt-get from recovery mode (which I prefer to scripts) as well , take your pick. Since you can not use sudo, you will have to boot to recovery mode. https://wiki.ubuntu.com/RecoveryMode be sure to remount / rx (see wiki) – Panther Oct 28 '17 at 17:27
  • @CharlesGreen thanks a ton for the thoughts on HOW this could have impacted so much. I guess I was attempting *.*, but never considered it would traverse up the tree like that. The removal of permissions to read/execute (execute is for indexing/listing a directory contents if I remember correctly?) explains my inability to do basically anything. Attempting an ls gives permission denied on /bin/ls. Although I had no recursive flag, guessing only contents directly under / would be impacted. – Brian Jorden Oct 28 '17 at 17:39
  • Tangentially related How should I glob for all hidden files? – Zanna Oct 29 '17 at 07:22

2 Answers2

4

Whew, the recovery here was actually smoother than I expected and everything SEEMS in pretty good shape again.

Huge thanks to @CharlesGreen for an explanation of how that command extended up a directory. Also thanks to @Panther for info on getting into recovery mode for a somewhat related issue. (if you both want to re-share your comments as answers I'd upvote them)

Fortunately, unlike the linked post, this seems to have had a very straightforward fix. It seems when I ran the sudo chmod 600 .* command from only one directory under / it expanded the .* portion UP to the true root directory altering permissions of . from / causing every other permission to fall over.

The "fix" for this was to boot into recovery mode, re-mounting the drive as read/write, going to the main root (cd /), and then chmod +rx .. After a reboot, everything looks to be back to normal.

Moral of the story, executing a command on .* can at least sometimes impact the directory ABOVE the current. I had intended to only impact files that started with ....oops.

Huge thanks to everyone that commented and helped.

Brian Jorden
  • 231
  • 1
    It probably affected parent directory 'cause .. matches .* glob. – Cthulhu Oct 28 '17 at 22:01
  • 1
    Yet another reason to use a saner shell. zsh, for example, does not include . or .. in the expansion of .* by default. – muru Oct 30 '17 at 08:44
2

The "fix" for this was to boot into recovery mode, re-mounting the drive as read/write, going to the main root (cd /), and then chmod +rx .. After a reboot, everything looks to be back to normal.

Just to be clear for future readers who might come across this as the accepted answer, there are concerns with the chmod +x solution as a general solution. This specific question appears to have been the users home directory so some of the concerns below may be low, but if this was applied to a business server and impacted multiple users or other data directories the solution is not suggested.

On the positive side, this step would permit the user to regain access to the files so they can be copied off to a backup medium to prevent further loss. And at the end of the day, that's the primary goal during any data recovery effort.

The biggest concern is that the original files might have had specific permissions applied that are now missing. Some programs - specifically ssh - enforce file permissions to further ensure their security and will not work if the +rw permission is set on its folder and files.

Another concern is if this is applied at the root (/) folder recursively, there will be other files that might be open for anyone on the system to view and modify. In a business setting where the server might contain sensitive data (PCI/financial, or healthcare/HIPAA information) this access could lead to audit findings and repercussions.

In a personal/home environment this recovery is probably perfectly acceptable. Just note that some things might be silently broken or act weirdly.

In a business environment, using this recovery to regain access to the data might be used, but ultimately any dramatic change like this should be resolved by re-installing the server and recovering from a backup.

( You DO have a current backup, don't you? ;-) )

dan_linder
  • 1,000
  • 2
    Went ahead and up voted because there is some generally useful advice/information here. In my particular situation I was fortunate enough that the only permissions that got altered were directly within / and did not cascade recursively into any other directories. Also worth noting, this was just on my personal laptop and although I might have lost part of a day's work (hadn't done a git push yet), it would have just been a huge hassle and annoyance to reinstall my "user" related applications. Had it been a server of any sort, I'd generally agree, less time and effort to just wipe / rebuild. – Brian Jorden Feb 20 '18 at 17:53