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.

jmiserez
  • 4,774
  • 2
  • 19
  • 22
Brij Raj Kishore
  • 2,088
  • 3
  • 13
  • 23
  • 12
    Related: http://serverfault.com/questions/364677/why-is-chmod-r-777-destructive – Glen Jul 18 '16 at 05: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 '16 at 09: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 '16 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 '16 at 07:10
  • Possible duplicate of [What if I accidentally run command "chmod -R" on system directories (/, /etc, ...)](http://askubuntu.com/questions/43621/what-if-i-accidentally-run-command-chmod-r-on-system-directories-etc) – Scott - Слава Україні Jul 19 '16 at 21:44
  • 4
    I would really LOVE to hear the story about you came to be asking this question. – Dewi Morgan Jul 20 '16 at 05:00
  • [Dewi](http://askubuntu.com/users/382617/dewi-morgan) I ran this command on ubuntu and I had to regret it resulted in the loss of data and time resulted due to a system crash. I was able to log in but nothing is working no launcher, no right click, and not even the terminal is opening via keyboard shortcut . – Brij Raj Kishore Jul 20 '16 at 15:48

4 Answers4

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.

Zanna
  • 69,223
  • 56
  • 216
  • 327
Peter Green
  • 1,825
  • 1
  • 10
  • 15
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.

Pilot6
  • 88,764
  • 91
  • 205
  • 313
  • 11
    Maybe someone will take time and make a detailed answer ;-) – Pilot6 Jul 17 '16 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 '16 at 21:01
  • 1
    Accoring To You [Pilot6](http://askubuntu.com/users/167850/pilot6) after running chmod now i need not requires the sudo to run. Its like I have removed sudo and not every command needs sudo then why it have to go and crash. Unstable I got it because of security reasons but once i ran the command sudo chmod -R 777 / It actually crashed my system. My launcher right-click, nothing was working after login. – Brij Raj Kishore Jul 17 '16 at 21:02
  • 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 '16 at 21:02
  • 1
    The system is crashed because important system programs do not run with this permissions. They are designed this way. If you do not like this design, you can create your own OS and do whatever you like. – Pilot6 Jul 17 '16 at 21:04
  • 9
    So [Pilot6](http://askubuntu.com/users/167850/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](http://askubuntu.com/users/167850/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
  • 1
    You are correct. I know 3-4 examples. If noone writes a good answer with details, I will add some information later. – Pilot6 Jul 17 '16 at 21:14
  • Then why does the system crashes and not simply an error occurs? – JobHunter69 Jul 17 '16 at 21:28
  • 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 '16 at 00:45
  • I think this link useful, I was tried it on ubuntu12.04, work well: http://sysadminnotebook.blogspot.in/2012/06/how-to-reset-folder-permissions-to.html – Nullpointer Jul 18 '16 at 07:15
  • "A short answer." It's not very short, but it _is_ hopelessly vague. This doesn't explain why the intuition 'surely permissions are fine because I'm giving everyone permissions' is wrong, e.g. because `chmod NNN` trashes gid/uid info - nor does it provide any believable example of a program that would refuse to run if numeric permissions weren't to its liking, e.g. OpenSSH. – underscore_d Jul 19 '16 at 07:05
  • Well, it is not unsuable. Only few programs like sudo or ssh will refuse to run. Compare it with removing libc or glibc and you will see what is unusable. – rdllopes Jul 20 '16 at 12:02
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.

wallyk
  • 774
  • 5
  • 13
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.

Ben XO
  • 276
  • 2
  • 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 '16 at 21:00
  • 1
    so [Ben](http://askubuntu.com/users/282183/ben-xo) 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 09: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 09:17
  • i know the security is serious in ubuntu but I am curious that as you mention about sticky bit in chmod, then would my command 1777 will be harmful for security but it will not be result in crash? [Ben](http://askubuntu.com/users/282183/ben-xo) – Brij Raj Kishore Jul 21 '16 at 10:23
  • 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 '16 at 13:26