7

I read here that chmod -R 777 / is a very bad idea, because it overwrites permissions on files and deactivates the setuid, setgid, and sticky bits.

However I was thinking that chmod -R ugo+rwx / would not overwrite the permissions but add them, if not there already present, and that it would be therefore much safer than the aforementioned command. It also doesn't turn off any of the special bits, if I'm not mistaken.

Am I right? Or are those commands basically the same and both would destroy my system?

I don't intend on doing it, just asking for general culture.

5
  • 2
    you could try it and find out! (create /tmp/moonstroke and put some setuid, setgiud, etc files in there; create a tarball for easy restoration, then go for it!) Commented Jul 18, 2016 at 17:50
  • see man chmod Commented Jul 18, 2016 at 17:54
  • 3
    Important note: doing that will make your system unusable. Commented Jul 18, 2016 at 17:55
  • 1
    I bit safer. However in the case of doing -R on /, it is like the difference between “being hit by a small bullet that will just about kill you, and being hit by a bigger bullet.”: It will make your system less secure that a Microsoft's Windows OS. Commented Jul 18, 2016 at 18:01
  • 4
    It's sort of like asking "is it better to drill out my door lock or just leave it unlocked?" The latter is easier to fix, but in both cases you can still lose everything in your house. Commented Jul 18, 2016 at 18:25

2 Answers 2

11

You would strip all security from your system making it extremely vulnerable. Lots of programs would stop functioning due to insecure permissions. You are technically right it would append those rather than over write so you would keep SGID and SUID permissions. I have an old Ubuntu machine I no longer need so I figured I would test this. After running chmod -R ugo+rwx / sudo stopped working due to insecure perms on /usr/lib/sudo/sudoers.so . ssh stopped working because I was using rsa keys which also required strict permissions. I couldn't reboot the machine in the OS because sudo was broken however the power button worked just fine. I was surprised because the server actually booted up just fine, I could probably fix it with single user mode but I am just going to reinstall. So to answer your question, no. While chmod -R ugo+rwx / is technically different than chmod -R 777 / it is not safer because they both break your system.

3
  • 5
    Tip: you should have tested this in a snapshotted VM, then reverted to the snapshot. Commented Jul 18, 2016 at 23:49
  • 1
    How is chmod -R ugo+rwx / different than chmod -R 777 / ? Commented Jun 22, 2022 at 21:43
  • 1
    @h0r53, chmod -R ugo+rwx adds rwx to a file where 777 explicitly sets equal it to rwx,. As a result, with ugo+rwx sticky bits are not cleared where with 777 sticky bits are cleared. A truly identical command would be chmod ugo=rwx Commented Oct 2, 2023 at 22:06
1

I thin these commands are not the same because you are using + in symbolic representation rather than = , so your observation may be correct but It is better to see the man page for chmod. man chmod

...................

 SETUID AND SETGID BITS
   chmod clears the set-group-ID bit of a regular file if the file's group ID does not match
   the  user's  effective  group ID or one of the user's supplementary group IDs, unless the
   user has appropriate privileges.  Additional restrictions may cause the  set-user-ID  and
   set-group-ID  bits  of  MODE or RFILE to be ignored.  This behavior depends on the policy
   and functionality of the underlying chmod system call.  When in doubt, check the underly‐
   ing system behavior.

   chmod  preserves  a  directory's  set-user-ID and set-group-ID bits unless you explicitly
   specify otherwise.  You can set or clear the bits with symbolic modes like u+s  and  g-s,
   and you can set (but not clear) the bits with a numeric mode.

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.