I hear that chmod 777 is a horrible idea. However, nobody else is ever going to use my system (and this is a quite common scenario for a lot of *nix systems). Why shouldn't I allow everything?
5 Answers
You might be the only human user on the system. But if you get a look at /etc/passwd you'll see that there a lot of other users:
root:x:0:0:root:/root:/bin/ash bin:x:1:1:bin:/bin:/sbin/nologin daemon:x:2:2:daemon:/sbin:/sbin/nologin adm:x:3:4:adm:/var/adm:/sbin/nologin lp:x:4:7:lp:/var/spool/lpd:/sbin/nologin sync:x:5:0:sync:/sbin:/bin/sync shutdown:x:6:0:shutdown:/sbin:/sbin/shutdown halt:x:7:0:halt:/sbin:/sbin/halt mail:x:8:12:mail:/var/mail:/sbin/nologin news:x:9:13:news:/usr/lib/news:/sbin/nologin uucp:x:10:14:uucp:/var/spool/uucppublic:/sbin/nologin operator:x:11:0:operator:/root:/sbin/nologin man:x:13:15:man:/usr/man:/sbin/nologin postmaster:x:14:12:postmaster:/var/mail:/sbin/nologin cron:x:16:16:cron:/var/spool/cron:/sbin/nologin ftp:x:21:21::/var/lib/ftp:/sbin/nologin sshd:x:22:22:sshd:/dev/null:/sbin/nologin at:x:25:25:at:/var/spool/cron/atjobs:/sbin/nologin squid:x:31:31:Squid:/var/cache/squid:/sbin/nologin xfs:x:33:33:X Font Server:/etc/X11/fs:/sbin/nologin games:x:35:35:games:/usr/games:/sbin/nologin cyrus:x:85:12::/usr/cyrus:/sbin/nologin vpopmail:x:89:89::/var/vpopmail:/sbin/nologin ntp:x:123:123:NTP:/var/empty:/sbin/nologin smmsp:x:209:209:smmsp:/var/spool/mqueue:/sbin/nologin guest:x:405:100:guest:/dev/null:/sbin/nologin nobody:x:65534:65534:nobody:/:/sbin/nologin nginx:x:100:101:nginx:/var/lib/nginx:/sbin/nologin vnstat:x:101:102:vnstat:/var/lib/vnstat:/bin/false redis:x:102:103:redis:/var/lib/redis:/bin/false These are system accounts i.e. accounts that run the different services and daemons on the system: web servers, mail services (incoming and outgoing), ftp servers, cron jobs, etc.
Usually these services run on their own directory and do their stuff like good boys. But, in case of a bug or, more likely, if someone hacks your machine through one of these services (e.g. web server), you don't want these user accounts to have unrestricted full read-write access on your whole system.
In short, you have nothing to gain and everything to lose by giving these users more access than they need. This is called the principle of least privilege.
(Note: the password file is taken from here.)
- 1Not to mention : the human user IS human. Granting humans godlike power rarely leads to good outcomes, even if they do things accidentally. Requiring you to elevate before performing certain actions prevents the user from making a bunch of mistakes (like the classic
rm -rfin a system folder).Adrian– Adrian2025-02-03 16:33:42 +00:00Commented Feb 3 at 16:33 - chmod 777 is not godlike power. this "answer" makes a somewhat valid point however I disagree with the initial statement of there are a lot of other users then goes on to contradict that statement by stating these are system accounts (which is true) but also neglects to mention
/sbin/nologinon those accountsron– ron2025-02-05 16:03:23 +00:00Commented Feb 5 at 16:03 - @ron The fact that these "users" are denied from login reduces the attack surface but does not invalidate my point.dr_– dr_2025-02-05 17:21:11 +00:00Commented Feb 5 at 17:21
You asked,
I hear that chmod 777 is a horrible idea. […] Why shouldn't I allow everything?
and then mentioned in a comment,
I have been having permission issues getting Steam to download games on another filesystem
If it's a Linux-native filesystem you can either change the mount point to your owner, or if you must then set it to be writeable for all users. This second option is not ideal because of the principle of least privilege: you don't give access unless it's necessary/appropriate. You can't predict what might happen so you don't allow what you don't expect.
Example
# Take ownership sudo chown "$USER" /path/to/mountpoint If you've already downloaded items as root but really should have downloaded them as yourself, use the recursive flag to take ownership of everything under the filesystem mountpoint
sudo chown -R "$USER" /path/to/mountpoint Note that if you try these commands on / or any of the system directories you will break your system.
- 1Nice parsing of the user's issue while providing general and specific advice. +1.Wyrmwood– Wyrmwood2025-02-01 18:27:01 +00:00Commented Feb 1 at 18:27
One significant technical reason is that some security-relevant programs refuse to work with files that are too permissive. For example, sshd will not use a .ssh/authorized_keys file unless it has very restrictive permissions.
Secondly, you can make your system unbootable by accidentally removing or trashing files in /etc or otherwise. Forcing yourself to use sudo or whatever you need to do to modify those files is a step in saving yourself from your own errors.
A further, more psychological reason: working with permissions is something that you will be doing constantly, on Unix*ish systems. If you get used to just applying 777 everywhere, you will never be challenged with the small details that are relevant on "real" systems (i.e. those that are not only used by a single person, with a very restrictive amount of apps, and no security-relevant data). This means you are denying yourself the chance to get used to this, and develop an intuition of how these things work.
After all, once you are "breathing" the permission system, it will be very, very simple indeed. The defaults, i.e. the default umask and such things, are "sane" on modern systems, so in most cases you can just work with it; especially if you are alone on the system.
If ever you work on a more sensitive system, especially in a business context, you will be very happy that the permissions are second-nature.
Applying chmod 777 to system files and directories WILL break your system
This question intrigued me so much, that I did chmod -R 777 /* on my home rhel-9.4 system. As expected the /run folder responded with read-only file system and the /proc folder did not take. After doing this I was able to yum update and successfully reboot and log in to rhel-9.5. However the verbose boot did show fail for security auditing service and ssh service, and ssh specifically recognizing its key file permissions too open so that's why it doesn't start. And then firefox will open but trying to go to any website says "cannot access" like the internet doesn't work.
so to say break your system is kind of out of context. I mean if there was no internet or network access at all it was completely standalone and isolated, then the stuff/services that deal with permissions related stuff but in general if you are not needing them then it is kind of hard to pin down the ramifications of a global chmod 777. You're basically saying let everything run, and with some rational exceptions like I mentioned, I think things will.
Now you did not explicitly state what folders doing a chmod 777 on would happen. So, assuming doing something like chmod 777 /steam where it is just one folder, I'm sorry to put off a lot of people but I've dealt with this for the last 20 years at work going back to SGI IRIX days and NO a chmod 777 is not fundamentally bad. It is largely a matter of context, and if other logical rational security is in place like only one user and physical location being the primary security mechanism for a single-user auto login setup, a 777 can be done and not cause problems. It would be like saying an inner lock box is bad when it is already inside a lock box. I'm positive you can chmod 777 a lot of system files and have a functioning system, but only a lazy not-so-intelligent person would swing that hammer system wide to fix a problem that is not system wide.
in your context with steam games, which means internet, which means 3rd party software and bugs and security, and playing against other users, would a blanket chmod 777 on all things steam be ok in Linux, I do not know. I would not bet $1 that it would.
- You ran the command as root, presumably? Otherwise it would have only affected your own files and directories, which pretty much will only be your home directory and its contentsChris Davies– Chris Davies2025-02-01 12:04:44 +00:00Commented Feb 1 at 12:04
- 5I would have expected the PAM subsystem to break, along with all the other authentication/authorisation tools like
sudo,su,sshd,login.Chris Davies– Chris Davies2025-02-01 12:06:00 +00:00Commented Feb 1 at 12:06 - 3Indeed,
chmod 2777 foobarmakes a file setgid,chmod 777 foobarclears the setuid/setgid/sticky bits because777=0777. If you didchmod ugo+rwxit would set the low 9 bits without modifying the high octal digit of the permission bitmask. (@ChrisDavies).chmod ugo=rwxclears the high bits like777.Peter Cordes– Peter Cordes2025-02-02 00:22:08 +00:00Commented Feb 2 at 0:22 - on my home system having a separate ssd for rhel-9.4 linux I logged in as root, and did
chmod 777 /<folder>for each top level folder present in a default install of rhel-9.4-x86_64-dvd.iso.ron– ron2025-02-03 02:54:16 +00:00Commented Feb 3 at 2:54 - and my point here is simply... if you have accounted for all security aspects that mitigate doing a
chmod 777 /*such as no internet or network and complete physical security of system then it becomes a hard sell as to whychmod 777is a problem specifically regarding security if that's what everyone is harping on. But again, context matters... steam games and internet then yeah probably not a good idea.ron– ron2025-02-03 02:56:44 +00:00Commented Feb 3 at 2:56
Why shouldn't I allow everything?
Because even rudimentary security on a system should not fail utterly if a single one of your assumptions is false.
The reason is that it provides you with more security to handle permissions at least somewhat restrictive, so that the next bug in service XYZ doesn't leak your home-made porn collection and banking details to the world.
777is not "maximum permissions", it's minimum, allowing Read, Write and eXecute by any user, in any group. Applyingchmod 777to system files and directories WILL break your system.