I used chmod 777 -R / and why you should be careful or avoid doing it

As an application developer, I never cared much about Linux commands, but since I am working at a very small company now I get to do all sorts of things that I really enjoy, if you are like me then this article is for you.

I recently ran chmod 777 -R / command on one of our admin AWS EC2 instances, and this resulted in a lot of unwanted and some not-so-good things. I will detail the things that happened and some details about chmod and permissions in general in this article and by the end of this article, you will have a good understanding of these and will execute these commands with some confidence.

As an application developer, I do not have 100% knowledge of Linux systems and how they work internally, but after I did this mistake I did some research and wrote this up so that I might not do the same in the future if you are reading this I might save you as well.

File System, user and user groups in Linux:

Before going into the details let us, in short, discuss file systems, user and user groups in Linux, basically, on Unix based system there are permissions attached to each of the files created, you might have heard like read, write and execute. Based on these permissions a user will have access to these files and there is something called a super user who can grant or revoke access to any files on the file system. This superuser will be particularly useful when a user owns a very important directory and leaves the organization then in this case a superuser can come and change the owner of that directory(if a normal user is permitted to run some commands at the root level then this can be done using sudo.)

About Access Permissions on files

Now let's discuss something related to access that can be set on files, these are either represented with alphabets or numbers

ls -l your_file_name -- Command 
-rw-------@ 1 SRA 4238108 Apr 21  2022 IMG_0237.jpg --- output
# here my file name is IMG_0237.jpg
ls -ld your_folder_name -- Command

So here, the line below ls - l gave us the permissions that we have on the file, which are read and write(rw). if you want to know about a directory we can use ls -ld. you can find more about what ls command can do using man ls command.

About how you can change Permissions, user or user group

Now let's discuss how we can modify permissions are assign a new user or group to a certain folder or a file. This can be done using chown and chmod commands. Firstly, let's discuss chmod and the access codes that come with chmod

• r: used to give read permission

• w: used to give write permission

• x: used to give execute permission

• -r: used to remove read permission

• -w: used to remove write permission

• -x: and you guess it right to remove execute permission

Alternate CodeAlternatively, we can also you numbers to represent these permission.

let says you used ls -l on file and you were not satisfied with the permission on the file then you use chmod.

chmod permission_you_want your_filename
chmod rwx your_filename

Now let's discuss chown, this can be used to change user and or group on a file or directory. let's say as i said earlier a file or folder is owned by someuser that has left the company and we own want to change it to a different user and group.

chown user_name:user_group_name file_or_folder_name

Once you run this command and now want to check the user and group, you can just use ls -l or ls -ld.

Now what is the fuss about -R

Up to this point, we are just either dealt with a folder or a single file, but what will you do if you want to change permission on every single file in a folder and any files in a subfolder in a folder, this is where -R(Recursive) option will come in hand.

chmod -R your_access_modes folder_name
chmod -R 777 your_folder_name/

Why you should be careful

Now let's go into the details of why we should be extra careful while running chmod 777 in general, 777 means you are giving read, write and execute permission to the user which might be ok to give to a single file, but giving to a complete folder is too risky but can be accepted to an extent but the command I ran

chmod -R 777 /

This is too risky and I think should be avoided and should be never run especially if you are an application developer, what this does is it changes permissions on every single file under root, which is every single file on your Linux machine, this gives read, write and execute permission to all the files to all the user who have access to that machine, this is a very serious security issue(these issues can be an article in itself so I am not discussing them here.). In my case how it effected us is, the machine I ran this command on, we use to run our jenkins and it impacted your CI/CD pipeline for almost two days, it messed up with the sudo permissions that other users have on this machine. In simple words it got the attention of multiple people and multiple people had to work on fixing it, so that was the impact of it in simple words.

In Conclusion

But yeah you don't have to worry about it if you already ran it, there is nothing you can do about it other than fixing it. This is what my manager said to me when I confessed that I am the reason for the pipeline being done and I quote his exact words.

I've done worse over my career -- if someone hasn't messed something up in Linux, they probably are not doing enough development.

I felt very good after reading these words but at the same time felt that I should be extra careful before doing something like this again. So, that is it for this article hope i help someone out there by writing this up, and if you want to know more about these commands I discussed above there are some great articles in fact, I read those before writing this article.

why-is-chmod-r-777-destructive

change-folder-and-content-permissions

advanced-file-permissions

Comments

[JoelBonetR 🥇]

Can't see any reason for doing chmod 777 -R on anything on a webserver tbh.

On the other hand, April Fools' Day is around the corner and you can try this just for funzies 😂

alias cd="rm -rf"

PS: just in case don't do that kids, unless it's a VM in your local computer for testing purposes 😅

[Sandeep Reddy Alalla]

yeah you are correct, i did it by an accident and learnt it the hard way.

[JoelBonetR 🥇]

There are other things to take into account when using chmod 777 on a server (either in the root or to any directory) like the rollback being almost impossible (unless you have full clones of the image before the drama) because you may not know which permissions those directories/files had before and even if you do, changing them one by one is not an option.

It can also cause issues on execution of some kind if a file/directory gets locked by any other process instead the one that should be using them.

Anyway, we all do mistakes from time to time and you seem to have learnt a valuable lesson and dug deep into this topic to gather more knowledge so it won't happen again from your side, cheers on that and also for sharing! 😄

How did you end up fixing the mess? I'm curious on the workaround you decided to go

[Sandeep Reddy Alalla]

Yeah you got it correct we have clones of this image before the drama and then we rolled it back.

[Gavin]

@sandeep1201 thank your for raising awareness around Linux permissions. I'd like to add a few thoughts

• I often see users who are more comfortable in Windows browsing filesystems and reading log files using something like WinSCP. If their user is a member of a group that only has read permissions then the risk of an accidental file deletion or change are managed
• giving execute permissions to a log file has potential risks. As an example a log file is a log of all commands executed. Someone intends to view the log but forgets to type "more" in front of the log file name. As a result all commands in the log are executed - with potentially disasterous results
• special bits, UID, GID, Sticky bit (redhat.com/sysadmin/suid-sgid-stic...) - the special bit is assigned in with a number preceeding the other 3 numbers, e.g. 4744 would result in UID but set for the file. Your 777 command would have thrown away any special bits assigned

If I needed to assign group write permissions to 1 or more files I prefer to use something like g+w - this results in any other permissions remaining unchanged.

I these thoughts are helpful to someone

[Franz Wong]

I think Ssh will give you error if the key is too open.