Fix setuid and setgid bits in /usr?
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!
Solution 1:
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.
Solution 2:
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.