diary/Kojima
・su と sudo
ちと root ユーザで bdftopcf 等のコマンドを実行しようと /etc/login.defs の ENV_SUPATH 設定に /usr/X11R7/bin を追加したのだけど、
sudo でビルドスクリプトを実行すると /usr/X11R7/bin にパスが通っていない。
% su
パスワード: ＊＊＊＊
bash-3.2# env | grep -i path
PATH=/usr/X11R7/bin:/sbin:/bin:/usr/sbin:/usr/bin
PKG_CONFIG_PATH=/usr/X11R7/lib/pkgconfig:/usr/lib/pkgconfig
bash-3.2# exit
exit
kojima@athlon[~]% sudo env | grep -i path
パスワード: ＊＊＊＊
PATH=/bin:/usr/ucb:/usr/bin:/usr/sbin:/sbin:/usr/etc:/etc
/usr/ucb なんてパスをどこで設定しているのかしばらく悩んだのだけど、考えてみると sudo はログインしない（/bin/login は通らない）ので、
/etc/login.defs は読まないので、私のログインシェルである tcsh のコンパイル時に組み込まれたデフォルト値っぽい。
/etc/csh.login とか /etc/csh.cshrc とかで設定しても反映されないところを見ると、コンパイル時に修正しないとダメなのかな？
- などと書いたけど、strings で /bin/tcsh を見ても /usr/ucb というパスは無いので、あれれ、と思って調べたら sudo 自体が設定するパスらしい。 -- kojima
- さらに sudo の man ページとかを調べると sudo PATH=/usr/X11R7/bin ... みたいに変数を明示することで直接渡せるらしい。なかなか奥深いというか、日々是修行、という感じだな（苦笑 -- kojima
- 素朴な疑問ですけど、tcsh使いの人がsuでrootになるとき、シェルがbashになるのって辛くありませんか？ 私は元々bash使いなので、suでのrootがbashで違和感なかったのですが、今回の例を見て気になってしまいました。たしか、shadowutils由来のsuは実効uidとPATH環境変数だけを変更し、シェルは変更されないものと思っていたのですが。ついでに、rootではなく他の一般ユーザへのsuだと、シェルはどうなるのでしょう。まさか、変更先のログインシェル依存？ -- azuki
- これは以前から気になっていたのですが solaris 辺りでは /etc/ucb なんてディレクトリもありませんでしたっけ < ほんのチョコッと触った程度で、記憶曖昧
。 sudo PATH ... までは調べていませんでした。 -- M.Tomi
- まぁ、最近では tcsh も bash も機能的にほとんど差が無くなった（最近の bash だと >& でエラー出力もリダイレクトできるようになったし）のでそれほど気にならないというか、むしろ普段 tcsh で su で root になった時は bash という方が、普段とは違う環境にいることが自覚できて各種操作に注意するというメリットがありそうな（笑 それから、本来 su は Super User ではなくて Substitute User だから、他の一般ユーザに切り替える時はそのユーザのログインシェルに切り替わるはずだけど、多分、SHLVL=1 にはならないので、読み込む設定ファイルはログインシェルとは微妙に異なるんじゃなかったかな。 -- kojima
- ちょっと勘違いしていました。伝統的なsuは、USER, HOME, SHELL以外の環境変数は引き継がれるようです(厳密には、rootにsuするときに限り、USER環境変数は変更されない)。SHELLは、ターゲット先のログインシェルになるみたい。rootへのsuで、tcshからbashに変更される件は了解しました。でも、プロンプトがbash-3.2# というのはちょっと残念な感じ。bashからだと、ちゃんとroot@host:/home/user# ってなります。 -- azuki
- 同じrootへのsuでも、X立ち上げたkterm上で行ったときは、bashであってもプロンプトがbash-3.2# となります。X立ち上げたkterm上だと、なぜかPS1シェル変数が引き継がれないようです。 -- azuki
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
