54

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.

Improve this question
7
  • 12
    Related: serverfault.com/questions/364677/why-is-chmod-r-777-destructive
    – Glen
    Jul 18, 2016 at 5:00
  • 2
    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, 2016 at 9:02
  • 7
    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, 2016 at 15:12
  • 6
    @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, 2016 at 7:10
  • 4
    I would really LOVE to hear the story about you came to be asking this question.
    – Dewi Morgan
    Jul 20, 2016 at 5:00

4 Answers 4

Reset to default
107

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.

Improve this answer
41

A short answer.

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.

Improve this answer
12
  • 11
    Maybe someone will take time and make a detailed answer ;-)
    – Pilot6
    Jul 17, 2016 at 20:55
  • 1
    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, 2016 at 21:01
  • 4
    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, 2016 at 21:02
  • 9
    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, 2016 at 21:08
  • 13
    @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, 2016 at 0:45
33

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
/opt/google/chrome/chrome-sandbox
/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/VBoxHeadless
/usr/lib64/virtualbox/VBoxNetDHCP
/usr/lib64/virtualbox/VBoxNetAdpCtl
/usr/lib64/virtualbox/VBoxVolInfo
/usr/lib64/vte/gnome-pty-helper
[root@fedora23lnvr61]#

I removed dozens of noise entries in caches and logs.

Improve this answer
7
  • 3
    Dare I wonder why gnuchess and rogue are on that list?
    – WiseOldDuck
    Jul 18, 2016 at 20:05
  • 2
    @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, 2016 at 20:24
  • 3
    @WiseOldDuck As wallyk says, plus, remember setuid doesn't nessecarially have to use root (and afaik setgid isn't really useful for root)
    – Weaver
    Jul 18, 2016 at 20:28
  • 5
    Up'd for bothering to explain what chmod is doing and provide example evidence, something that's very lacking elsewhere.
    – underscore_d
    Jul 19, 2016 at 7:03
  • 1
    Does this mean that chmod u+rwx,g+rwx,o+rwx -R / will not break the system?
    – Dennis Jaheruddin
    Jul 20, 2016 at 10:46
15

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.

Improve this answer
6
  • 4
    "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, 2016 at 21:00
  • 1
    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, 2016 at 15:45
  • Thanks @hvd - you're right and I have changed the post slightly to reflect that.
    – Ben XO
    Jul 21, 2016 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, 2016 at 9:17
  • 1
    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, 2016 at 13:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.