Strode 氏は、環境変数の「最新」ソリューションへの移行を望んでいるものの、壊れたシステムが広く公開されることによるプレッシャーを感じているのは明らかです。したがって、この記事の執筆時点でのバグに関する彼の最新のコメントは、「ええ、私はこれについて屈服することを検討しています」となっています。したがって、Fedora 25 では、ログイン シェルをログイン プロセスに復元する更新が行われる可能性があります。「適切な修正」は後日になります。
今は Fedora 28 ですが、"適切な修正" の方向はどこでしょうか? ユーザーがセッションの環境変数を設定するための将来を見据えた方法はまだありますか?
つまり、Fedora で動作する代替品であり~/.bash_profile、できれば他の場所でも動作します。
答え1
GNOME 3.24の場合、Strodegnome-session を元に戻しましたログインシェルを実行して環境変数を読み込みます。
同じコメントで、これらのセッション環境変数を systemd ユーザー サービスにプッシュするための gnome-session のパッチも含まれています。これらには が含まれるgnome-terminalため、かなり重要です :)。
GDMセッションランチャーはすでにパッチを当てた3.22 では、 から環境をインポートしますsystemd --user。したがって、 systemd 環境はセッションにインポートされ、ログイン シェルによって変更され、結果も にコピーされますsystemd --user。
これは問題なく動作するはずですが、Fedora 28 でのテストを除き、gdm セッション ランチャーでは systemd 環境変数による既存の環境の上書きが許可されないため、PATH などでは正しく動作しません。GNOME問題追跡システムで報告しました。
そうだった同意したlogin（テキストコンソール用）できたユーザーのシェルを起動する前に環境設定をロードするためのパッチを受け入れますが、今のところ変更はありません。ユーティリティ Linux v2.32。
私は ssh パッチを探す気にもなれませんでした :)。
systemd環境は既に設定可能でしたuser.conf。この取り組みの一環として、systemd v233獲得した既存のリストや検索リストenvironment.d/にディレクトリを先頭に追加することなどをサポートするようになった形式です。PATHLD_LIBRARY_PATH
ユーザー ログイン用の環境変数を設定する最適な場所は PAM モジュールであると考えましたpam_env。すでに そのように設定されています。論理は
login、gdm、sshd（決して起こりません）などにこれを実行するよう要求するのは、実際には貧弱な解決策です。
残念ながら、 の設定はディストリビューションpam_env間で矛盾しており、それには何か理由があるようです。~/.pam_environmentセキュリティ上の大きな「フットガン」と見なされている参照脆弱性。
たとえば、次の例を見てください
pam_exec。システム管理者がこれを使用してログイン後の設定などを行うことは想像できますが、ユーザーは LD_PRELOAD を設定することで root になることができます。または、pam_selinux は実際には pam_getenv を直接使用するため、ユーザーはそれをいじることができます。しかし、私のポイントはこれらの特定の例ではなく、root として実行することにはリスクがあること、そしてログイン プロセスの少し後の段階で実行することで、それらのリスクを完全に回避し、潜在的なセキュリティ バグのクラス全体を排除できることを説明することです。一般的なルールとして、コードを root として実行する必要がない場合は、root として実行しないでください。もちろん、私はまだ迷っています。論理的には後で実行する方が面倒だからです。しかし、root として実行する方がユーザーとして実行するよりもリスクが高いことには疑いの余地がありません。pam_exec のマニュアルには、次のように明記されています。「pam_exec によって呼び出されるコマンドは、ユーザーが環境を制御できることを認識する必要があります。」
pam_env については、Fedora はこれを pam スタックの最上位に配置し、デフォルトで ~/.pam_environment を無効にすることに注意してください。
これをスタックの一番上に置くのはバグであり、これを行わないようにという明示的な警告に違反します: 「PAM 環境変数の設定は他のモジュールに副作用をもたらす可能性があるため、このモジュールはスタックの最後に置く必要があります。」
[...] ここでの混乱を考えると、これは明らかにフットガンである
これにシェル設定を使用するという一般的な考え方は、たとえば Ubuntu Desktop 16.04 のグラフィカル ログインでも機能するようです。ただし、違いが 1 つあります。Fedora は~/.bash_profileデフォルトで を作成しますが、これは (bash の場合)~/.profile無視されます。Ubuntu およびその他の Debian ベースのディストリビューションは、~/.profile代わりにデフォルトで を作成します。(つまり、これらのファイルは、 から新しいユーザーを作成するときに提供されます/etc/skel)。
（最近Ubuntuでこれを使用しました。UbuntuはGUIセッションのログインシェルの実行に関して時間の経過とともに変更されたようです。例えば、https://superuser.com/questions/183870/bashrc と bash プロファイルの違い/183980#183980、https://askubuntu.com/questions/40287/etc-profile-not-being-sourced、「なぜgnome-terminalはログインシェルではないのか」、 そして「シェルログインの意味 ('bash -l')」）。