我做了一件蠢事：
chown -R root:root /usr
chmod -R g-w /usr
显然，我能做的最好的事情就是重新安装系统。但是，到目前为止，我的系统运行良好 - 不尽快修复此问题会有什么立即危险吗？我有 Ubuntu 18.04（没有互联网连接），它只是用作本地 NAS。
我这样做的原因是由于更新时出现警告：
WARN: uid is 0 but '/usr' is owned by 1000
WARN: /usr is group writable!
我问了一下，论坛上有人建议使用上述命令，并说“这绝对安全”。教训是：不要相信互联网上的人，即使他们听起来完全相信。
显然，之所以/usr组可写但不属于 root，是因为我的特定 DIY-Nas Ubuntu（Odroid）：
drwxrwxr-x 10 odroid odroid 4096 Apr 12 2018 usr
也许我不应该使用-R递归选项。现在这不重要了。
在过去的几个小时里，我浏览了各种帖子，以了解我做了什么。它看起来像是chown在运行任何/usr中断setuid和setgid位，因此一旦我再次修复所有权，我就需要手动与现有系统进行比较以恢复所有这些。对于修复sudo命令，我已经这样做了：
chown root:root /usr/bin/sudo && chmod 4755 /usr/bin/sudo
除此之外，我没有看到任何其他问题。当我登录 Ubuntu 界面时，我收到一些蓝牙软件的权限警告，但这不是立即相关的。我知道 /usr 中有一些软件有一个除root（参见此处列出，例如），出于安全原因 - 但这是否会对我的 nas 系统产生任何真正的负面影响，尤其是与文件处理/存档相关的影响，例如损坏或无法访问的文件？
请注意，我创建了一个新的 stackexchange 帐户，因为我太尴尬了。无论如何，非常感谢您的建议！
答案1
我认为你很幸运，因为你刚刚删除了组的“可写”位。这不会影响 SETGID 或 SETUID 位。如果之前已设置，则仍会设置。chmod -R 777 /usr另一方面，该命令重置将所有位都删除，rwx同时删除任何其他位，包括s位。这就是为什么发行者chmod -R 777 /usr通常被迫重新安装的原因。
也许我对我的系统所做的观察可以帮到你。我运行了一些find命令来查看哪些文件和目录会受到你发出的命令的影响。结果如下：
# 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
当然，您的里程可能会有所不同，但我相信您只“破坏”了少数文件。下面绝大多数对象
/usr都归 或root:root所有。删除该位实际上不会造成伤害，因为它会删除组的可写位，但（至少在我的标准系统上）该组的唯一成员无论如何都是用户，他通过用户权限（您没有更改）拥有写访问权限，并且实际上不需要通过组成员身份获得写访问权限。rwxrwxr-xrwxr-xr-xg-wrootroot
顺便说一下，my/usr本身有以下属性：
drwxr-xr-x 10 root root 4096 Jan 5 2018 usr/
更新
楼主提到他遇到了这个错误
sudo: /usr/bin/sudo must be owned by uid 0 and have the setuid bit set
在发出chmod g-w和chown root:root之后，必须用来修复它
chmod 4755 /usr/bin/sudo。事实证明，chown g-w确实不会更改 setuid 位但确实如此chown root:root。它显然清除了那些 SETUID（可能还有 SETGID 和 STICKY）位。对我来说，这是意料之外的行为，但我很确定肯定有解释和/或理由。但是。我运行了另一个find
命令来查看下面哪些文件/usr设置了一个或多个 SETUID、SETGID 和 STICKY 位：
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
这个列表不是很长，但仍然包含一些我认为至关重要的文件。特别是最后三分之一的文件，例如passwd，
crontab等等，当然还有sudo。
答案2
我认为 @PerlDuck 的上述回答解释了最重要的事情。在手动处理每个文件后，我认为我消除了最大的混乱。如果这台电脑暴露在互联网上，我会立即重新安装 - 现在我有更多的时间。
无论如何，我想在这里添加一个 Linux 默认权限完整列表的链接： https://www.vidarholen.net/contents/junk/ubuntu_permissions.html这也帮助我恢复了一些额外的文件权限。