268

This is a Canonical Question about File Permission and Why 777 is "destructive".

I'm not asking how to fix this problem, as there are a ton of references of that already on Server Fault (reinstall OS). Why does it do anything destructive at all?

If you've ever ran this command you pretty much immediately destroy your operating system. I'm not clear why removing restrictions has any impact on existing processes. For example, if I don't have read access to something and after a quick mistype in the terminal suddenly I now have access well... why does that cause Linux to break?

gWaldo
  • 11,887
  • 8
  • 41
  • 68
samwise
  • 2,383
  • 2
  • 14
  • 9

2 Answers2

356

First of all a minor terminology nitpick: chmod doesn't remove permissions. It CHANGES them.

Now the meat of the issue -- The mode 777 means "Anyone can read, write or execute this file" - You have given permission for anyone to do (effectively) whatever the heck they want.

Now, why is this bad?

  1. You've just let everyone read/modify every file on your system.
    • Kiss password security goodbye (anyone can read the shadow file and crack your passwords, but why bother? Just CHANGE the password! It's much easier!).
    • Kiss security for your binaries goodbye (someone can just write a new login program that lets them in every time).
    • Kiss your files goodbye: One user misdirects rm -r / and it's all over. The OS was told to let them do whatever they wanted!
  2. You've pissed off every program that checks permissions on files before starting.
    sudo, sendmail, and a host of others simply will not start any more. They will examine key file permissions, see they're not what they're supposed to be, and kick back an error message.
    Similarly ssh will break horribly (key files must have specific permissions, otherwise they're "insecure" and by default SSH will refuse to use them.)
  3. You've wiped out the setuid / setgid bits on the programs that had them.
    The mode 777 is actually 0777. Among the things in that leading digit are the setuid and setgid bits.
    Most programs which are setuid/setgid have that bit set because they must run with certain privileges. They're broken now.
  4. You've broken /tmp and /var/tmp The other thing in that leading octal digit that got zero'd is the sticky bit -- That which protects files in /tmp (and /var/tmp) from being deleted by people who don't own them.
    There are (unfortunately) plenty of badly-behaved scripts out there that "clean up" by doing an rm -r /tmp/*, and without the sticky bit set on /tmp you can kiss all the files in that directory goodbye.
    Having scratch files disappear can really upset some badly-written programs...
  5. You've caused havoc in /dev /proc and similar filesystems
    This is more of an issue on older Unix systems where /dev is a real filesystem, and the stuff it contains are special files created with mknod, as the permissions change will be preserved across reboots, but on any system having your device permissions changing can cause substantial problems, from the obvious security risks (everyone can read every TTY) to the less-obvious potential causes of a kernel panic.
    Credit to @Tonny for pointing out this possibility
  6. Sockets and Pipes may break, or have other problems Sockets and pipes may break entirely, or be exposed to malicious injection as a result of being made world-writeable.
    Credit to @Tonny for pointing out this possibility
  7. You've made every file on your system executable
    A lot of people have . in their PATH environment variable (you shouldn't!) - This could cause an unpleasant surprise as now anyone can drop a file conveniently named like a command (say make or ls, and have a shot at getting you to run their malicious code.
    Credit to @RichHomolka for pointing out this possibility
  8. On some systems chmod will reset Access Control Lists (ACLs)
    This means you may wind up having to re-create all your ACLs in addition to fixing permissions everywhere (and is an actual example of the command being destructive).
    Credit to @JamesYoungman for pointing out this possibility

Will the parts of the system which are already running continue to run? Probably, for a while at least.
But the next time you need to launch a program, or restart a service, or heaven forbid REBOOT the box you're in for a world of hurt as #2 and #3 above will rear their ugly heads.

Isaac Turner
  • 103
  • 3
voretaq7
  • 79,345
  • 17
  • 128
  • 213
  • 1
    At least on some systems `/tmp` would be fixed after a reboot. Though everything lots of other things appears to be broken. At least in VM I just tested on it appears a reboot fixed the `/tmp` permissions. There must be something in a startup script somewhere. – Zoredache Feb 28 '12 at 22:02
  • @Zoredache Systems that use `tmpfs` usually fix themselves, ones that have /tmp on disk *may* (depends on their startup scripts) – voretaq7 Feb 28 '12 at 22:06
  • 47
    +1 for pointing out that setuid and setgid would be eliminated. This is a hugely destructive aspect. Try running `find / -perms -4000 -type f` and `find / -perms -2000 -type f` to see various binaries that rely on these flags. – Kyle Smith Feb 28 '12 at 22:33
  • 3
    Typing something like "less foo.txt" would not execute a file called less.txt laying around regardless of executable bit being set. You would need to have the directory less.txt was in in your path and you would have to type "less.txt foo.txt" - not really an accidental thing there. Even if you were using shell completion it would stop at less and you would still have to add the .txt. To call a random text file with executable bit set you'd have to ./nameoffile.txt. – The Real Bill Feb 29 '12 at 03:40
  • So this might be one of the shortests scripts ever made to use as linux malware payload (given that the user runs it as root)? – Mister Smith Feb 29 '12 at 17:29
  • I don't see it being particularly useful as a malware payload. `rm -rf /` is shorter and more destructive. This can be fixed by re-applying permissions (which a lot of package management software can do with no problems) – voretaq7 Feb 29 '12 at 17:38
  • Define "everyone"? Everyone in the entire world? Everyone with internet access? Everyone who has access to the FTP in the first place (in which case setting 777 is no problem for like 99.999% of servers anyway)? Plenty of people explain vaguely what these permissions are, but I just don't understand whether a random web visitor is considered part of the permissions at all? – Deji Dec 03 '15 at 13:49
  • 3
    @Deji `everyone` is defined as the union of set including the user who owns the file, users in the group which owns the file, and users who do not meet either of those criteria (literally the three octal permission digits: `User`, `Group`, and `Other`). In other words *any user with access to the system*. ("Access" in this context could be a shell account, which is how I would normally address it, but it also includes access through a web form/CGI which writes data to disk: The `www` user can now write to any file on the system, which means random visitors can too.) – voretaq7 Dec 16 '15 at 22:40
  • Much of this answer makes the tacit assumption that this is applied to the entire file system. As a canonical question, would it be worth discussing the dangers of applying this to a *limited* portion of the file system (say, your WordPress directory)? – jpmc26 Mar 14 '16 at 05:40
103

One major thing is that there are many tools like ssh/sudo that check the filesystem permissions for key config files. If the permissions are wrong, these tools are designed to fail, as this would indicate a serious security problem. On my Debian test system and perhaps on others, the ability to login fails, probably because the login binary or something in PAM has permission checks.

So it isn't really that the system is destroyed -- it's that many tools are designed to immediately fail when the permissions are wrong.

If you reboot a system after doing a chmod 777 -R / it will boot, and you can start processes that don't have explicit permission checks. So the system isn't really dead, just somewhat unusable by-design.

belacqua
  • 583
  • 4
  • 10
Zoredache
  • 128,755
  • 40
  • 271
  • 413