須藤対ルート;実際の違いはありますか？

sudo を使用してプログラムを呼び出す方法に大きく依存しますまたは su .
例えば。今私がいるシステム:

                  .bashrc                        
    COMMAND        $HOME   $USER  Env.  $PATH
 1. sudo -i        (root)   root  root  [1]
 2. sudo -s        (USER)   root  USER  /home/${USER}/bin:[1]
 3. sudo /bin/bash (USER)   root  USER  /home/${USER}/bin:[1]  
 4. sudo su        (root)   root  USER  [1]:/usr/games:/usr/local/games  
 5. sudo su -      (root)   root  root  [1]

ここで [1]=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
Env=2、3、4 で $USER から取得された 1 と 5 の環境変数がリセットされます。

したがって、別のオプションで起動されたスクリプトまたはプログラムは、別の $PATH を参照できます。、 $HOME 、そのシェルは異なる .bashrc を読み取ることができます ,.profile および環境変数。 $HOME に関連するファイルを読み込みます .各ユーザーは、異なる方法で環境を変更できます (変数、$PATH 、.bashrc、.profile、.bash_profile、エイリアス...)。特に、ユーザーは $PATH でディレクトリの順序を変えることができます結果として、スクリプトはコマンドを実行できます。 /home/$USER/bin で代わりに、ルートから期待されるパス内のもの。

プログラムは sudo -i で実行できます su - でルートとしてログインしたため 、ただし、sudo MyCommand で実行すると、異なる動作をすることができますまたは su -c MyCommand で .

man su から :

<ブロック引用>

説明部分:
現在の環境が新しいシェルに渡されます . $PATH の値がリセットされました 通常ユーザーの場合は /bin:/usr/bin に、スーパーユーザーの場合は /sbin:/bin:/usr/sbin:/usr/bin に
...
オプション部分で：
- 、-l、--login
に似た環境を提供するユーザーが直接ログインした場合にユーザーが期待すること .

男 sudo から

<ブロック引用>

-私、 - ログインする
ターゲットユーザーのパスワードデータベースエントリで指定されたシェルをログインシェルとして実行します。これは、.profile や .login などのログイン固有のリソースファイルがシェルによって読み取られることを意味します。コマンドが指定されている場合は、シェルの -c オプションを介して実行するためにシェルに渡されます。コマンドが指定されていない場合、対話型シェルが実行されます。 sudo シェルを実行する前に、そのユーザーのホームディレクトリに移動しようとします。 コマンドは、ユーザーがログイン時に受け取る環境と同様の環境で実行されます . sudoers(5) マニュアルのコマンド環境セクションには、sudoers ポリシーが使用されている場合に、コマンドが実行される環境に -i オプションがどのように影響するかが記載されています。

sudo がいっぱいの場合アクセスすると、root になることができます sudo su - を使用、したがって、セキュリティポイントは意味がありません。

実際、root として実行されたプログラムの違いを識別する方法があります。プログラムは sudo で実行されました - getuid を使用 vs geteuid -しかし、これは不自然なトリックです。なぜパッチシステムはそれを行うのでしょうか?

@Hastur が指摘したように、ルートシェルを取得している場合は、いくつかの違いがあります。

root シェルを取得していない場合は、さらに違いがあります。サポートメンバーは sudo patch -p0 < /root/patch.file のようなことを試みた経験があるかもしれませんどこで patch ルートとして実行されますが、< (ファイルからのパイプ) ではありません。