Strodeは環境変数の「現代的な」ソリューションに切り替えたかったのですが、破損したシステムへの広範な暴露による圧迫感をはっきりと感じました。したがって、この記事を書いている時点で、バグに関する彼の最近のコメントは次のとおりです。「はい、この問題を削除することを検討しています」したがって、Fedora 25では、ログインプロセスに対する「適切な修正」を復元するアップデートが表示されます。後でお待ちください。
Fedora 28です。 「正しい修正」の面では、私たちはどこにいますか？ユーザーがセッションの環境変数を設定できるようにする予防的な方法はありますか？
~/.bash_profileつまり、Fedoraとは異なる場所でも機能する代替品です。
ベストアンサー1
GNOME 3.24ではStrode復元されたGNOMEセッションログインシェルを実行して環境変数をロードします。
同じコメントには、これらのセッション環境変数をsystemdユーザーサービスにプッシュするためのgnome-sessionパッチが含まれています。これらは含まれているのでgnome-terminal非常に重要です:).
GDMセッションランチャーにはパッチ済み3.22ではsystemd --user。したがって、systemd環境をセッションにインポートし、ログインシェルによって変更され、結果が再度コピーされますsystemd --user。
うまく動作する必要があります... Fedora 28でのテストを除いて、gdmセッションランチャーはシステム環境変数が既存の環境をオーバーライドすることを許可しないため、たとえばPATHでは正しく機能しません。GNOME問題トラッカーに問題を報告しました。。
それ同意する（loginテキストコンソールの場合）できるユーザーシェルを起動する前に、環境設定をロードするためにいくつかのパッチを受け入れましたが、これまでの変更はありません。ユーティリティLinux v2.32。
私はSSHパッチを見つけることを気にしませんでした:).
systemd環境はすでに設定可能ですuser.conf。このタスクの一環として、systemd v233得るenvironment.d/これで、既存または検索リストへの追加のディレクトリの追加をサポートする形式です。PATHLD_LIBRARY_PATH
私は、ユーザーログイン用の環境変数を設定するのに最適な場所はPAMモジュールだと思います。私たちはすでにそうしていますpam_env。 ロジックは
このためにログイン、gdm、sshd（絶対に発生しない）などを要求するのは本当に悪い解決策です。
残念ながら、構成はpam_envディストリビューション間で不快なほど一貫性がなく、ここにはそのような理由があるようです。~/.pam_environment特徴安全とみなされる大きな「銃」。また、見ることができますCVE-2010-4708。
pam_execたとえば、見てください。システム管理者がログイン後の設定やその他の操作を実行するためにこれを使用すると想像できますが、ユーザーはLD_PRELOADを設定してroot権限を取得できます。あるいは、 pam_selinux は実際に pam_getenv を直接使用するため、ユーザーはそれを操作できます。しかし、私のポイントは、これらの具体的な例ではなく、rootでこれを実行する危険性があり、後で実行してこれらのリスクを完全に迂回し、潜在的なセキュリティバグクラス全体を排除できることを説明することです。ログインプロセス。通常、コードをrootとして実行する必要がない場合は、rootとして実行しないでください。もちろん、後で行うのは論理的にもっと厄介なので、まだ混乱しています。しかし、rootにすることがユーザーにするよりも危険であることは間違いありません。pam_exec マニュアルには次のように明確に記載されています。 "pam_execが呼び出すコマンドは、ユーザーが[sic]環境を制御できることに注意してください。"
について。 pam_env、fedora はそれを pam スタックの一番上に置き、デフォルトで ~/.pam_environment を無効にします。
スタックの一番上に置くのは間違いであり、そうしないでくださいという明示的な警告に違反します。 「PAM環境変数の設定は他のモジュールに副作用を引き起こす可能性があるため、このモジュールはスタックの最後にある必要があります。」
[...] 混乱を考えると、これは明らかにライフルです
シェル構成を使用する一般的なアイデアは、Ubuntu Desktop 16.04グラフィカルログインにも当てはまるようです。しかし、違いがあります。 Fedoraは~/.bash_profileこれをデフォルトで生成し、（bashの場合）~/.profile無視されます。 Ubuntuやその他のDebianベースのディストリビューションは~/.profileデフォルトで作成されます。 （つまり、新しいユーザーを作成すると、このファイルが提供されます/etc/skel。）
（最近、Ubuntuでこれを使用しました。Ubuntuは時間の経過とともに変更されているように見え、GUIセッションのログインシェルを実行しません。例を参照してください。）https://superuser.com/questions/183870/difference-Between-bashrc-and-bash-profile/183980#183980、https://askubuntu.com/questions/40287/etc-profile-not-being-sourced、「gnome-terminalがログインシェルではない理由」と「シェルログインとはどういう意味ですか（ 'bash -l'）」）。