Csdrhrt

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!

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 '%Mt%u:%gt%pn'

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.

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.