7

I did something stupid:

chown -R root:root /usr
chmod -R g-w /usr

Apparently, the best thing I can do is reinstall the system. However, my system works fine so far - is there anything immediately dangerous not fixing this asap? I have Ubuntu 18.04 (no Internet connection), it is just used as a local NAS.

The reason I did this was due to a warning when doing updates:

WARN: uid is 0 but '/usr' is owned by 1000
WARN: /usr is group writable!

I asked and someone in a forum suggested the above commands with "it is perfectly safe". Lesson learned: Don't trust people on the Internet, even if they sound totally convinced.

The reason, apparently, why /usr was group writable and not owned by root is because of my specific DIY-Nas Ubuntu (Odroid):

drwxrwxr-x  10 odroid odroid     4096 Apr 12  2018 usr

Perhaps I should have not used the -R recursive option. It doesn't matter now.

The last few hours, I looked through various posts to find out what I did. It looks like running any chown on /usr breaks setuid and setgid bits, so I would need to manually compare to an existing system to restore all of those once I have fix the ownership again. For fixing sudo command, I already did this:

chown root:root /usr/bin/sudo && chmod 4755 /usr/bin/sudo

Besides this, I don't see any more problems. When I log in to Ubuntu interface, I get a permission warning from some Bluetooth Software, but it is not immidiatly relevant. I understand that there is some software in /usr that has a group other than root (see list here, for example), for reasons of security - but will there be any really negative effects on my nas-system, especially related to file handling/archive things, e.g. corrupted or inaccessible files?

Note that I created a new stackexchange account because I am too embarrassed.. anyway, many thanks for suggestions!

Helmut
  • 103

2 Answers2

8

I think you were lucky because you just removed the "writable" bit for groups. This won't affect the SETGID or SETUID bits. If they were set before, they are still set. The command chmod -R 777 /usr on the other hand resets all bits to rwx while removing any other bits at the same time, including the s bits. This is why people who issued chmod -R 777 /usr are usually forced to do a re-install.

Maybe the observations I made on my system can help you. I have run some find commands to see which files and directories would have been affected by the commands you issued. Here are the results:

# Find all files and directories NOT owned by user root:
find usr -not -user root -ls
3407926     52 -rwsr-sr-x   1 daemon   daemon      51464 Feb 20  2018 usr/bin/at

# Find all files and directories NOT owned by group root:
find usr -not -group root -ls
3418319      4 drwxrwsr-x   3 root     staff        4096 Jan  5  2018 usr/local/lib/python3.6
3418322      4 drwxrwsr-x   2 root     staff        4096 Jan  5  2018 usr/local/lib/python3.6/dist-packages
3419229      4 drwxrwsr-x   4 root     staff        4096 Nov 13 20:03 usr/local/lib/python2.7
3419230      4 drwxrwsr-x   2 root     staff        4096 Jan 26  2018 usr/local/lib/python2.7/dist-packages
1049153      4 drwxrwsr-x   2 root     staff        4096 Nov 13 20:03 usr/local/lib/python2.7/site-packages
3544477      4 drwxrwsr-x   2 root     staff        4096 Jan  5  2018 usr/local/share/fonts
3418324      4 drwxrwsr-x   3 root     staff        4096 Jan  5  2018 usr/local/share/emacs
3544479      4 drwxrwsr-x   2 root     staff        4096 Jan  5  2018 usr/local/share/emacs/site-lisp
3416934    372 -rwsr-xr--   1 root     dip        378600 Jun 12 19:20 usr/sbin/pppd
3410196     40 -rwxr-sr-x   1 root     mail        39000 Apr  3  2018 usr/sbin/ssmtp
3408208     12 -rwxr-sr-x   1 root     utmp        10232 Mär 11  2016 usr/lib/x86_64-linux-gnu/utempter/utempter
3419827     12 -rwxr-sr-x   1 root     tty         10232 Aug  4  2017 usr/lib/mc/cons.saver
3428536     16 -rwxr-sr-x   1 root     mail        14336 Jul 31 16:14 usr/lib/evolution/camel-lock-helper-1.2
3416858     44 -rwsr-xr--   1 root     messagebus  42992 Nov 15  2017 usr/lib/dbus-1.0/dbus-daemon-launch-helper
1183416      4 drwxrwsr-t   2 root     lpadmin      4096 Nov  8  2017 usr/share/ppd/custom
3410118     44 -rwxr-sr-x   1 root     mlocate     43088 Mär  1  2018 usr/bin/mlocate
3408029     16 -rwxr-sr-x   1 root     tty         14328 Jan 17  2018 usr/bin/bsd-write
3414379    356 -rwxr-sr-x   1 root     ssh        362640 Nov  5 12:51 usr/bin/ssh-agent
3410676     32 -rwxr-sr-x   1 root     tty         30800 Jul 26 18:20 usr/bin/wall
3409008     72 -rwxr-sr-x   1 root     shadow      71816 Jan 25  2018 usr/bin/chage
3416771     24 -rwxr-sr-x   1 root     shadow      22808 Jan 25  2018 usr/bin/expiry
3407926     52 -rwsr-sr-x   1 daemon   daemon      51464 Feb 20  2018 usr/bin/at
3409356     40 -rwxr-sr-x   1 root     crontab     39352 Nov 16  2017 usr/bin/crontab

# find objects that have the group-writable bit set and are owned by user=root but group!=root:
find usr -perm -0020 -user root -not -group root -ls
3418319      4 drwxrwsr-x   3 root     staff        4096 Jan  5  2018 usr/local/lib/python3.6
3418322      4 drwxrwsr-x   2 root     staff        4096 Jan  5  2018 usr/local/lib/python3.6/dist-packages
3419229      4 drwxrwsr-x   4 root     staff        4096 Nov 13 20:03 usr/local/lib/python2.7
3419230      4 drwxrwsr-x   2 root     staff        4096 Jan 26  2018 usr/local/lib/python2.7/dist-packages
1049153      4 drwxrwsr-x   2 root     staff        4096 Nov 13 20:03 usr/local/lib/python2.7/site-packages
3544477      4 drwxrwsr-x   2 root     staff        4096 Jan  5  2018 usr/local/share/fonts
3418324      4 drwxrwsr-x   3 root     staff        4096 Jan  5  2018 usr/local/share/emacs
3544479      4 drwxrwsr-x   2 root     staff        4096 Jan  5  2018 usr/local/share/emacs/site-lisp
1183416      4 drwxrwsr-t   2 root     lpadmin      4096 Nov  8  2017 usr/share/ppd/custom

Of course, your mileage may vary have varied but I'm confident that you only "broke" a handful of files. The vast majority of objects below /usr are owned by root:root and usually have either rwxrwxr-x or rwxr-xr-x. Removing the g-w bit doesn't really do harm because it removes the writeable bit for the group root but (at least on my standard system) the only member of that group is the user root anyway and he has write access via the user permissions (which you didn't change) and doesn't really need write access via group membership.

Btw, my /usr itself has the following attributes:

drwxr-xr-x  10 root root  4096 Jan  5  2018 usr/

Update

The OP mentions he faced the error 

sudo: /usr/bin/sudo must be owned by uid 0 and have the setuid bit set

after issuing chmod g-w and chown root:root and had to fix it with chmod 4755 /usr/bin/sudo. As it turns out, the chown g-w indeed does NOT change the setuid bit but the chown root:root did. It apparently clears those SETUID (and presumably also the SETGID and STICKY) bits. To me, this is unexpected behaviour but I'm pretty sure there's an explanation and/or reason. However. I ran another find command to see which of my files below /usr have one or more of SETUID, SETGID, and STICKY bits set:

find usr -perm /7000 -printf '%M\t%u:%g\t%p\n'
drwxrwsr-x  root:staff      usr/local/lib/python3.6
drwxrwsr-x  root:staff      usr/local/lib/python3.6/dist-packages
drwxrwsr-x  root:staff      usr/local/lib/python2.7
drwxrwsr-x  root:staff      usr/local/lib/python2.7/dist-packages
drwxrwsr-x  root:staff      usr/local/lib/python2.7/site-packages
drwxrwsr-x  root:staff      usr/local/share/fonts
drwxrwsr-x  root:staff      usr/local/share/emacs
drwxrwsr-x  root:staff      usr/local/share/emacs/site-lisp
-rwsr-xr--  root:dip        usr/sbin/pppd
-rwxr-sr-x  root:mail       usr/sbin/ssmtp
-rwxr-sr-x  root:utmp       usr/lib/x86_64-linux-gnu/utempter/utempter
-rwsr-sr-x  root:root       usr/lib/xorg/Xorg.wrap
-rwxr-sr-x  root:tty        usr/lib/mc/cons.saver
-rwsr-sr-x  root:root       usr/lib/snapd/snap-confine
-rwxr-sr-x  root:mail       usr/lib/evolution/camel-lock-helper-1.2
-rwsr-xr--  root:messagebus usr/lib/dbus-1.0/dbus-daemon-launch-helper
-rwsr-xr-x  root:root       usr/lib/openssh/ssh-keysign
-rwsr-xr-x  root:root       usr/lib/policykit-1/polkit-agent-helper-1
-rwsr-xr-x  root:root       usr/lib/eject/dmcrypt-get-device
drwxrwsr-t  root:lpadmin    usr/share/ppd/custom
-rwxr-sr-x  root:mlocate    usr/bin/mlocate
-rwxr-sr-x  root:tty        usr/bin/bsd-write
-rwsr-xr-x  root:root       usr/bin/traceroute6.iputils
-rwsr-xr-x  root:root       usr/bin/gpasswd
-rwxr-sr-x  root:ssh        usr/bin/ssh-agent
-rwsr-xr-x  root:root       usr/bin/passwd
-rwsr-xr-x  root:root       usr/bin/pkexec
-rwsr-xr-x  root:root       usr/bin/sudo
-rwxr-sr-x  root:tty        usr/bin/wall
-rwsr-xr-x  root:root       usr/bin/chfn
-rwxr-sr-x  root:shadow     usr/bin/chage
-rwsr-xr-x  root:root       usr/bin/arping
-rwxr-sr-x  root:shadow     usr/bin/expiry
-rwsr-sr-x  daemon:daemon   usr/bin/at
-rwxr-sr-x  root:crontab    usr/bin/crontab
-rwsr-xr-x  root:root       usr/bin/chsh
-rwsr-xr-x  root:root       usr/bin/newgrp

This list is not very long but it still contains some files I'd consider crucial. Especially those in the last third, like passwd, crontab, etc., and of course sudo.

PerlDuck
  • 13,335
  • Many thanks for the effort to list those files! I will investigate a bit more, change those groups-settings and oberserve if anything still appears strange. Thank you also for your explanation, which is even more helpful. However, what I don't understand: if the removing the writable bits for groups doesn't affect won't affect the SETGID or SETUID bits, why did I have problems with my sudo command, that is sudo: /usr/bin/sudo must be owned by uid 0 and have the setuid bit set? See here – Helmut Dec 08 '18 at 16:14
  • @Helmut Oh. I just tried, you are right. I stand corrected. I opened a terminal and did sudo -i to get a root shell. Then I did chown root:root /usr/bin/sudo and indeed, the setuid bit has gone and sudo is broken :-( The setuid bit isn't removed by the chmod g-w but by the chown. I'm afraid my whole answer has proved wrong now. – PerlDuck Dec 08 '18 at 16:34
  • @Helmut I updated my post and added "my" SETUID/SETGID files. I'm not satisfied with my answer, though. Maybe I'll remove it because it is not a real answer but rather a list of files that would have been affected on my personal installation and yours is likely to be different. – PerlDuck Dec 08 '18 at 17:30
  • 1
    I think it really helps, please leave it. Changing those owners back won't solve all my problems, but I might survive until I can reinstall the system in a couple of weeks! - I removed the "correct answer" selection, nonetheless this is perhaps the only answer that can be given under my circumstances. – Helmut Dec 08 '18 at 17:36
  • @Helmut Ok. :-) Good to hear it helped you at least a bit. I think the most important thing is the sudo command. If that works, everything else can be recovered. – PerlDuck Dec 08 '18 at 17:38
  • In case you are interested: @ThomasWard pointed me to chown removes sticky bit: bug or feature? over on U&L. I wasn't aware of this behaviour. – PerlDuck Dec 08 '18 at 17:45
  • So.. I went through the list one by one and fixed users and sticky bits. They made sense when compared to other information - 19 of your items I could find. Anyway, I am aware this won't fix everything, but it is only supposed to provide me some time. Many thanks! Also for the link: I came to the conclusion that learning unix permissions this way is perhaps the best way to not forget them :) I didn't truly destroy anything at this point, but I may have in the future. – Helmut Dec 08 '18 at 18:15
3

I think the above answer from @PerlDuck explains most crucial things. After working through each file manually, I think I removed the largest mess. If this computer would have been exposed to the internet, I would have reinstalled right away - now I have some more time.

Anyway, I want to add a link to a complete list of Linux default permissions here: https://www.vidarholen.net/contents/junk/ubuntu_permissions.html This also helped me restore a number of additional file permissions.

Helmut
  • 103
  • 1
    Great finding. But the link you show tells e.g. for the sudo command: chmod 4755 /usr/bin/sudo; chown root:root /usr/bin/sudo. As we both just learned, the chown undoes the chmod 4xxx (removes the special bits). It's better to swap the two commands, i.e. chown first and then chmod. Nonetheless, that list is good. I'd first do grep -E 'chown.*/usr' and then grep -E 'chmod.*/usr' (or similar, untested) in your case and run the results in that order. – PerlDuck Dec 08 '18 at 19:41
  • 1
    Yes, totally true! I didn't actually follow this order, just looked up information for some links. Thanks for mentioning this. Also: I find doing chmod g+s /file/thatneeds/setgid and chmod u+s /file/thatneeds/setuid both more legible and less dangerous for typos. – Helmut Dec 09 '18 at 05:50