私は何か愚かなことをしました:
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
再帰オプションを使用すべきではありません。今では関係ありません。
過去数時間、私はさまざまな投稿を調べて、自分が何をしたかを調べました。 /usr
でchown
を実行しているように見えるsetuid
およびsetgid
ビットを壊すので、修正したらこれらをすべて復元するために既存のシステムと手動で比較する必要があります再び所有権。 fixing Sudo
command の場合、すでにこれを実行しました。
chown root:root /usr/bin/Sudo && chmod 4755 /usr/bin/Sudo
これに加えて、これ以上の問題は見当たりません。 Ubuntuインターフェースにログインすると、一部のBluetoothソフトウェアから許可の警告が表示されますが、すぐには関係ありません。セキュリティ上の理由から、/ usrにはroot
以外のグループを持つソフトウェアがいくつかあることを理解しています(たとえば、 ここにリストを表示 を参照してください)私のnasシステムでは、特にファイルの処理/アーカイブに関するものです。たとえば破損したファイルまたはアクセスできないファイル?
恥ずかしいので、新しいstackexchangeアカウントを作成したことに注意してください。とにかく、提案に感謝します!
グループの「書き込み可能」ビットを削除しただけで幸運だったと思います。これは、SETGIDまたはSETUIDビットには影響しません。以前に設定されていた場合、それらはまだ設定されています。一方、コマンドchmod -R 777 /usr
resetsすべてのビットを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-x
またはrwxr-xr-x
のいずれかを持っています。 g-w
ビットを削除しても、グループroot
の書き込み可能ビットが削除されるため、実際には害はありませんが、(少なくとも私の標準システムでは)そのグループの唯一のメンバーはユーザーroot
とにかく、彼はユーザーのアクセス許可(これは変更しませんでした)を介して書き込みアクセス権を持ち、グループメンバーシップを介して書き込みアクセス権を実際に必要としません。
ところで、私の/usr
自体には次の属性があります。
drwxr-xr-x 10 root root 4096 Jan 5 2018 usr/
OPは、彼がエラーに直面したと述べています
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ビットを変更しませんbut the chown root:root
した。明らかに、これらのSETUID(およびおそらくSETGIDとSTICKY)ビットもクリアします。私にとって、これは予期しない動作ですが、説明や理由があると確信しています。しかしながら。別のfind
コマンドを実行して、下のどのファイル/usr
に1つ以上の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
のような最後の3分の1のもの。
@PerlDuckの上記の回答が最も重要なことを説明していると思います。各ファイルを手動で処理した後、最大の混乱を取り除いたと思います。このコンピューターがインターネットにさらされていた場合、すぐに再インストールしたことになります。
とにかく、ここにLinuxのデフォルトのパーミッションの完全なリストへのリンクを追加したい: https://www.vidarholen.net/contents/junk/ubuntu_permissions.html これはまた、いくつかの追加のファイル許可を復元するのに役立ちました。