☰

シンボリックリンクのchmodの動作が間違っていますか？

tag-icon • tag-icon sudo symlink chmod
シンボリックリンクのchmodの動作が間違っていますか？

最近、私たちは多くのユーザーが使用している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 システムコールのマニュアルページも確認しました。どちらもシンボリックリンクループのエラーを返します。つまり、リンク権限ではなくファイル権限を変更する動作がカーネルレベルで決定され適用されます。

おすすめ記事