最近、私たちは多くのユーザーが使用しているRed Hat Linuxボックスで問題に直面しました。/usr/bin/sudoバイナリが接着力を失った。 rootユーザーが問題を解決するまで、操作はブロックされます（sudo展開とテストが必要です）。
この失敗の原因は...$HOME/bin/sが指すシンボリックリンクです/usr/bin/sudo。私はbashエイリアスがもう1つ悪く、シンボリックリンクがすべてのシェルで動作するより簡単な解決策だと思ったので、ポイントを作成し、「もしあれば」$HOME/bin/sCall upにコピーし/usr/bin/sudoました。結果は必須の4111ではなく0755権限でした。これで問題が解決し、ルートがログインし、sudoが復元されました。$HOME/bin$HOMEsudo chmod 755 $HOME/bin/*/usr/bin/sudo
man chmod（Red Hat、Ubuntu）：
chmod never changes the permissions of symbolic links; the chmod system
call cannot change their permissions. This is not a problem since the
permissions of symbolic links are never used. However, for each sym-
bolic link listed on the command line, chmod changes the permissions of
the pointed-to file.
私の質問は：バイナリへのシンボリックリンクを生成してはいけないので、これは私のせいですか、それとも動作が間違っていてchmodシンボリックリンクが指すファイルの権限を変更してはいけませんか？なぜこれが起こるのですかchmod？これは言いますか？
答え1
バイナリへのシンボリックリンクを作成しても大丈夫です。/binこれにより/usr/bin、ほぼ確実に多くのエイリアスを見つけることができます。ここでの問題は、sudo結果を完全に理解せずに使用することです。幸いにも永久的な損傷は起こらず、重要な教訓を得ました。実行可能であることを確認したい場合は、使用またはa+x交換してください。u+x〜のようにウーサー、とにかくエイリアスを使用する方が良いでしょう。
マニュアルページ自体でこれが行われる理由を説明します。シンボリックリンクの権限は重要ではなく、そのリンクが解決するファイルの権限のみが重要です。多くの場合、ユーザーはリンクが指すファイルのプロパティを変更したいと考えています。
また、chmod()Linux と BSD システムコールのマニュアルページも確認しました。どちらもシンボリックリンクループのエラーを返します。つまり、リンク権限ではなくファイル権限を変更する動作がカーネルレベルで決定され適用されます。
答え2
同意します。シンボリックリンクをシンボリックリンクと考えると、あまり意味がありません。
しかし、シンボリックリンクをハードリンクと考えると、より意味があります。
最初の行はman 7 symlinkまさに次のように言います。
Symbolic links are files that act as pointers to other files. To understand their behavior, you must first understand how hard links work. A hard link to a file is indistinguishable from the original file because it is a reference to the object underlying the original filename. [...] Changes to a file are independent of the name used to reference the file.
したがって、ハードリンクを使用すると、ファイルの権限を任意の名前に変更すると、すべての名前のデフォルト権限が変更されます。
ほとんどのツールはシンボリックリンクをたどろうとしているので、実際にハードリンクであるかのように偽装することができます。
Except as noted below, commands follow symbolic links named as command-line arguments. The mv(1) and rm(1) commands do not follow symbolic links named as arguments, but respectively attempt to rename and delete them. Commands traversing a file tree [...]
バイナリファイルへのシンボリックリンク（またはハードリンク）を作成すると便利な場合がありますが、今見つけたように問題を引き起こす可能性があるいくつかの極端なケースが生成されます。
つまり、ここで大きな問題はsudo必要ないときに使うことだと思います。
他のユーザーがあなたのものへの読み取りアクセス権を持っている必要がある場合、~/binこれはsudoまったく必要ありません。
あるいは、アクセス権がない場合は、アクセス権を付与したり（使用するなど）、chmod g+rx $HOME/binターボールを提供することもできます。
sudoそれでも使用するのが良いアイデアだと思う場合は、次のようないくつかの選択肢があります。
sudo chown -h $USER $HOME/bin/*
chmod 755 $HOME/bin/*
-hchownシンボリックリンクに従わないように指示する
chmod -R 755 $HOME/bin/*
-R上記のman 7 symlink。
sudo find $HOME/bin/ -type f -exec chmod 755 {} +
-type f（この場合）シンボリックリンクでexecコマンドを実行しないようにfind指示します。chmod
# as user 2
cd ~user2/bin
sudo tar -C ~user1/bin -cf - . | tar -xf -
rootとして実行するとtar -cfすべてのファイルが表示されますが、tar -xfuser2として実行すると抽出されたファイルはuser2の所有になります。
答え3
ミケルすでに言っていますが、彼の答えに埋もれています。したがって、実際に間違っているのは
sudo chmod 755 $HOME/bin/* # <<<< highly suspicious!
ホームディレクトリ内のファイルを操作するにはスーパーユーザー権限が必要であることが多少奇妙です。その人が自分のホームディレクトリで何かをする権限がないことがわかったら、盲目的にsudoを実行するのではなく、状況を調べる必要があります。繰り返します。sudoを盲目的に実行しないでください。。その人が逃げると、/home/guy/bin/s': Operation not allowed` というchmod 755 $HOME/bin/*エラーメッセージが表示されます。chmod: changing permissions of
しかし、エイリアスを作成することはお勧めできません。 （これを行う必要がある場合は、シンボリックリンクの代わりにシェルエイリアスを使用することをお勧めします。これはスクリプトでは使用できないことを意味します。s）これは無害な操作ではなく、実行時に3つの追加文字を入力できます。単一文字の別名を指定すると、スペルが間違っているリスクが高くなります。sudosudo
やや驚くべきことchmodに、ほとんどのメタデータ操作はシンボリックリンクターゲットで機能しますが、ほとんどのメタデータ操作はリンク自体で機能します。ただし、シンボリックリンクには有用な権限がありません。シンボリックリンクは作成されたり（生成および上書きのみ）実行されたり、ターゲットを非表示にしたりする意味はほとんどありません。 Unixバリアントはchmodシンボリックリンク（一部のシステムではサポートされていません）、そのターゲットに影響を与えるのか、それとも両方に影響を与えるのかが異なります。 Linuxではchmodターゲットに影響を与えます。
答え4
エイリアスの作成とファイルへのシンボリックリンクの作成はどちらも有効です（通常はエイリアスが優先されますが）。私はこの状況について「間違った」ことがないと思います。これが動作でchmodあるため、シンボリックリンクファイルの操作方法（変更されていない）がわかりました。chmod今後はこれを回避できます。このようなことが再び発生した場合は、解決策を知っています。