# Why does chmod 777 -R / leave the system unusable?

I'm only granting permission to all to do anything but why does the system crash by giving permissions only? I'm only modifying the permission not changing the files.

• – Glen Jul 18 '16 at 5:00
• I think, it is not crashing, but rather just abort boot process at some point. If you'd look at /var/log/syslog, you'd even figure out the reason. – Hi-Angel Jul 18 '16 at 9:02
• It's important to know that even if this didn't break things, it would not "grant permission to all to do anything". There would still be a large number of actions that only "root" (more precisely, a process with effective UID zero) could do. – zwol Jul 18 '16 at 15:12
• @Glen if by "related", you mean "exact duplicate that shows why we should be able to flag as dupe across sites", then sure! great link. ;) – underscore_d Jul 19 '16 at 7:10
• I would really LOVE to hear the story about you came to be asking this question. – Dewi Morgan Jul 20 '16 at 5:00

There are a couple of reasons.

First in addition to the usual read/write/execute permissions there are some other bits that file permissions contain. Most notably setuid and setgid. When a program with one of these permission bits is set is run it gets the "effective UID" and/or "effective GID" of the program's owner rather than the user that ran it. This allows programs to run with more permissions than the user that ran them. It is used by many crucial system utilities including su and sudo. Your chmod command clears these bits leaving the utilities unusable.

Secondly some programs (notably ssh) do a sanity check on file permissions and refuse to use files with permissions they see as insecure. This reduces the risk of careless admins accidentally leaving security holes but it makes dealing with wiped-out file permissions all the more painful.

Linux system requires specific permissions for certain programs like sudo, etc.

When you run chmod 777 -R / you wipe all permissions and replace them with 777. This makes the system unusable unless you manually restore all the permissions.

In practice it is much faster and easier to re-install.

The problem is that many system programs are designed a way that they do not start if they "do not like" the permissions. This is made for security reasons.

I think it is more important to explain how to handle the system design in paractice than to explain why each program fails to work with wrong permissons.

If you really want all users to have unlimited permissions in Ubuntu, you can add all users to the sudo group instead of changing file and directory permissions. That will have the same effect, but will not ruin the system.

Another way (a very bad one) is to activate root account and allow everyone to login as root.

• Maybe someone will take time and make a detailed answer ;-) – Pilot6 Jul 17 '16 at 20:55
• I could point to a better way to allow everybody to do everything on this system - but writing a in-depth article on why each binary needs its specific permissions, settings and flags is a bit too much, imho. ;-) – Phillip -Zyan K Lee- Stockmann Jul 17 '16 at 21:01
• Linux systems are not designed to allow everybody to do everything. You can enable root account and everyone can log as root for that. It is stupid, but this is the way. – Pilot6 Jul 17 '16 at 21:02
• So Pilot6 you mean to say that the system programs are been designed in such a way that if permission goes wrong then they are not allowed/ able to function properly? And Please Pilot6 if possible please provide deeper answer with examples and explanation why certain applications require limited permissions. Thanks. – Brij Raj Kishore Jul 17 '16 at 21:08
• @Goldname The crash is the error -- it's a whole number of programs saying "I can't perform critical functions with the system in this state, so I'm aborting" – Shadur Jul 18 '16 at 0:45

chmod has subtle nuances.

chmod 0777 behaves differently from chmod u+rwx,g+rwx,o+rwx in that the setuid and setgid are zeroed by the first and preserved by the latter.

That is why the system became unusable. You removed necessary setuid from a few programs.

Here is a list of setuid or setgid files on my Linux Fedora 23 laptop:

[root@fedora23lnvr61]# find / -perm /g+s,u+s
/var/log/journal
/var/log/journal/75e870eb13c74fbf97556a32ecf80ea2
/usr/bin/rogue
/usr/bin/gnuchess
/usr/bin/locate
/usr/bin/umount
/usr/bin/lbrickbuster2
/usr/bin/gpasswd
/usr/bin/crontab
/usr/bin/fusermount
/usr/bin/su
/usr/bin/at
/usr/bin/newuidmap
/usr/bin/sudo
/usr/bin/pkexec
/usr/bin/mount
/usr/bin/chsh
/usr/bin/newgrp
/usr/bin/passwd
/usr/bin/chage
/usr/bin/chfn
/usr/bin/write
/usr/bin/newgidmap
/usr/sbin/mount.nfs
/usr/sbin/lockdev
/usr/sbin/netreport
/usr/sbin/userhelper
/usr/sbin/usernetctl
/usr/sbin/unix_chkpwd
/usr/sbin/pam_timestamp_check
/usr/libexec/kde4/kdesud
/usr/libexec/kde4/kpac_dhcp_helper
/usr/libexec/dbus-1/dbus-daemon-launch-helper
/usr/libexec/qemu-bridge-helper
/usr/libexec/openssh/ssh-keysign
/usr/libexec/spice-gtk-x86_64/spice-client-glib-usb-acl-helper
/usr/libexec/utempter/utempter
/usr/libexec/abrt-action-install-debuginfo-to-abrt-cache
/usr/libexec/Xorg.wrap
/usr/lib/polkit-1/polkit-agent-helper-1
/usr/lib64/vte-2.90/gnome-pty-helper
/usr/lib64/virtualbox/VBoxSDL
/usr/lib64/virtualbox/VirtualBox
/usr/lib64/virtualbox/VBoxNetNAT
/usr/lib64/virtualbox/VBoxNetDHCP
/usr/lib64/virtualbox/VBoxVolInfo
/usr/lib64/vte/gnome-pty-helper
[root@fedora23lnvr61]#


I removed dozens of noise entries in caches and logs.

• Dare I wonder why gnuchess and rogue are on that list? – WiseOldDuck Jul 18 '16 at 20:05
• @WiseOldDuck: I expect the games have the bit so they can update their "high score" file but not allow any unprivileged user to do so. – wallyk Jul 18 '16 at 20:24
• @WiseOldDuck As wallyk says, plus, remember setuid doesn't nessecarially have to use root (and afaik setgid isn't really useful for root) – StarWeaver Jul 18 '16 at 20:28
• Up'd for bothering to explain what chmod is doing and provide example evidence, something that's very lacking elsewhere. – underscore_d Jul 19 '16 at 7:03
• Does this mean that chmod u+rwx,g+rwx,o+rwx -R / will not break the system? – Dennis Jaheruddin Jul 20 '16 at 10:46

Additional to the other replies: you also removed the "sticky bit" from /tmp (which usually has permissions 1777), and this could cause other unexpected problems, as programs would be able to write to or delete each-others' temporary files.

The sticky bit is a special permission which, whilst allowing anyone to create files in /tmp, only allows the person who created it to move or remove it.

• "and this would have prevented anyone but root from using the system /tmp directory." -- That doesn't seem right. It would still allow anyone to use the system /tmp directory. No sticky bit needed if user, group and others all have all rights. It would, however, allow anyone to remove others' files. – hvd Jul 19 '16 at 21:00
• so Ben If I run chmod 1777 -R / then there should not be problem as i am not clearing the sticky bit? – – Brij Raj Kishore Jul 20 '16 at 15:45
• Thanks @hvd - you're right and I have changed the post slightly to reflect that. – Ben XO Jul 21 '16 at 9:14
• @BrijRajKishore, the question remains as to why you're doing this in the first place. Ubuntu and the programs which comprise it aren't designed to be run "permissionless", for many reasons. It would be more sensible to "su" to root instead. – Ben XO Jul 21 '16 at 9:17
• It is unknown if it will result in a crash. It's totally possible that it will, because suddenly applications will be able to do things to each others temporary files - perhaps accidentally - and this may cause a crash. As Ubuntu is never tested like this, you will probably be the first person to find out. :-) On the other hand, setting the sticky bit on every single folder on the system may cause many other problems, with applications which were expecting to be able to manipulate programs because of group permissions on folder (i.e. folders with permissions 2777). – Ben XO Jul 21 '16 at 13:26