56

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,964

4 Answers4

109

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
  • 70,465
Peter Green
  • 1,841
  • 1
  • 12
  • 15
43

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
  • 90,100
  • 91
  • 213
  • 324
  • 12
    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 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 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
  • 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-don't-feed-the-AI 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
34

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
  • 784
16

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
  • 286
  • 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 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 – 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