環境変数、時代遅れの遺物？徹底解剖でスッキリ整理整頓！

だから俺は環境変数を使って、マウントされたファイルを指すようにしてるんだ。あとはデバッグ用のスイッチとか。

良い指摘だね、「scrub LD_*」が万能薬じゃないってのはその通り。

言いたかったのは「これで解決！」ってことじゃなくて、あくまで「こういうのもあるの忘れずにね」って感じ。

ユーザーの環境を引き継ぐ子プロセスを起動する場合、問題はLD_PRELOADだけじゃなくて、環境全体が攻撃対象になるんだよね（LD_LIBRARY_PATH、PYTHONPATH、NODE_OPTIONSとかも）。

ちょっとでも特権が必要な処理をするなら、一番良いのはまっさらな状態から始めること。必要最小限の、許可リストに基づいた環境をゼロから構築して、それをexecve()に直接渡すのが正解。

そうすれば、「他の人の環境を壊す」問題も、「悪意のある再注入」問題も両方避けられるよ。

execの前にLD_*を消去…LD_PRELOADのサプライズを避けるために。

これは効果的なセキュリティ対策ではないことに注意。LD_PRELOAD経由で自身を注入するライブラリは、明らかにexec*をインターセプトして子プロセスに再注入することもできる。（完全に無害なLD_PRELOADライブラリで、これと似たことをやったことがある。）

execの前にLD_*を消去するか、secure_getenvを使ってLD_PRELOADのサプライズを避ける。

それやると、他の人の環境を壊すことになるだけだよ。これらの環境変数はローダーによって読み込まれ、子プロセスを"セキュア"モードで実行すべきかどうかを確認するために、auxvでAT_SECUREなどをチェックして、LD_PRELOADを無視するんだ。

マジかよ

君がこれからコードを書くであろう6つのプラットフォームのうち5つはPOSIXをサポートしてるぞ。DOSで作業したいのか？完璧だとは言わないけど、あんなに広範囲な標準化は二度とないと思うよ。

(Linux, BSD, iOS, Mac, Android)。DOSがどれかはわかるよね？

DOSで作業したいの？

そんなこと言ってないし、誰にも勧めないよ（笑）

君がコードを書く6つのプラットフォームのうち5つがPOSIXをサポートしている...完璧だとは言わないけど、これほど広範囲な標準化は二度と起こらないと思うよ。

(Linux, BSD, iOS, Mac, Android)。そしてDOSは推測できると思う。

わかってるよ。僕自身も"unixファン/unix哲学の提唱者"みたいなものだし。それが今できる最善のことだ。ただ、何かがとても広まって、とても使われて、とても普及して、とても"古く"なると、長年の多くの人々の選択の上に築かれたレガシーの塊になるんだよね。それは避けられないと思う。これはもっと小さい"エコシステム"でも起こる。

みんなに叩かれるだろうけど、coreutils以外のプログラムの99%はおそらくLinuxとPOSIXが提供する機能の0.1%も使ってないってことに気づいてないんだよね。

君は間違ってない。むしろ、POSIX+Flat64BitMemoryは"現代的なアプリケーション"が上に構築される足場なんだ。これらの"現代的なアプリケーション"はLinuxの機能は必要なくて、ネットワーク接続とストレージがあればいい。POSIXは、これらの基本的なリソースをユーザースペースアプリケーションに提供する便利なプロバイダーにすぎない。

ああ、unixは長年、その上に色々なものを構築するのに十分なものだったし、これからもおそらく十分だろう。それが現実。世界は70年代のOSで動いてるけど、もっと良いものがないからそれでいいと思う。

それ考えたことなかったな。setenv()とgetenv()だけを使ってKafkaを書き直せるかも。

今でもKafkaよりは使いやすいんじゃないかな、たぶん。

職場でKafkaが導入された瞬間、「終わった…」って思ったね。

みんなDBのスイッチを切って、Kafkaを永続ストレージとして使い始めたんだ。Kafkaチームのリーダーは、バックアップさえなくて、アップデートに失敗したときに本番データの半分が消えてしまって、大騒ぎしてた。

UIアプリケーションからのKafkaイベントの送信待ちでUIアプリケーションが遅くなるほど、毎秒数万ものイベントが送信されてた。最終的に、Kafkaチームが実行していた8つのブローカーからのACKを待つのではなく、1つのKafkaブローカーからのACKだけを待つようにする素晴らしいフラグが見つかった。こうして、UIアプリケーションから送信されたKafkaイベントが時々消えるという事態が生まれたんだ。

正直言って、会社がある種の技術を人々に無理やり押し付けようとした瞬間、それはうまくいかないとわかる。誰も使い方やどこで使うべきかを知らない。誰も設定方法、エッジケース、そして4年間も放置されているバグを知らず、ただの混乱に終わるんだ。

マジかよ。Kafkaを永続ストレージとして使うほど間抜けなのはうちだけだと思ってた。この文章のすべてが心に突き刺さる。

まずはRedisを移植しようぜ。

Redisは既にMicrosoft ResearchのGarnetプロジェクトでどこでも実行できるように移植されてるよ。

それなら、Garnetをsetenv()とgetenv()で書き直す必要があるね。

西暦2060年、ついに人々は物体を過去に送る手段を開発した。彼らの最初の行動：グレッグ90がこのアイデアを投稿するのを阻止するために、サイバネティックな殺人マシンを送った。

🤷‍♂️🔫🤖 抹殺！

☠️

👻

ああ、このクソみたいな仕組みは全部30年前から受け継がれてて、スレッドが登場したのに全然変わってないんだよね。もしgetenv/setenvの動作をC標準ライブラリで完全に書き換えたら、動的にライブラリをリンクしてるアプリは、再コンパイルしなくてもそれを拾えるのかな？C標準ライブラリにはgetenv/setenvを使ってる関数が他にもあるから（特に、過去にRustの開発者を苦しめた時間サブシステム）、スレッドセーフなストレージに置き換えるのはマジで大変そうだよね。

問題は残念ながらAPIに組み込まれていて、実装の変更では解決できないんだ。getenvを呼び出すと、内部構造への生のポインタが返される。setenvまたはunsetenvを呼び出すと、その構造が変更される。関数内のロックだけでは、データ構造を変更しようとしている間に、別のスレッドでそれらの生のポインタが読み取られないことを保証できない。これを安全にする唯一の方法は、メモリリークさせることだ。なぜなら、ポインタが一度渡されると、APIはユーザーがいつそれを使い終わるかを知る方法がないから。

これを安全にする唯一の方法はメモリリークさせることだろう。なぜなら、ポインタが一度渡されると、APIはユーザーがいつそれを使い終わるかを知る方法がないから。

いやいや、他のCのAPIがやってるように、ユーザーにバッファを渡させてそこにコピーすればいいだけじゃん。バッファが小さすぎたらエラーにするけど、サイズを報告する（か、明確に定義された"最大"値を返す）。

これにはAPIの変更が必要だ。提案されている修正は、関数のシグネチャを同じに保つものだ。

ああ、APIを修正するのが理想的だね。APIを変更せずに実装を修正できるかどうかというコメントに返信していたんだ。それはメモリリークさせる場合にしかできない。

これも、すべてを.ymlファイルに保存して、それらを簡単に配布したり、そこから他のどんなターゲット形式にも変換したファイルを配布したりできるようにした理由の一つだよ。

つまり、名前が有効であっても、シェルが文字、数字、アンダースコア以外のものをサポートしていない可能性があります。

それこそが、その主張を裏付ける答えのように聞こえるんだけど。

え？！それはまったく別の（そして真実の！）話だよ。大文字小文字の話でもPOSIXの話でもない。シェルが英数字以外の名前を扱えない可能性があるって話だ。それは全くその通りで、例えばBashは、"文字、数字、アンダースコアのみで構成され、文字またはアンダースコアで始まる"変数名のみをサポートしている。そして、有効な名前の環境変数のみをサポートしている。

いや、それはリンク先の回答が主張していることとは全く違う。自分で確認してごらん。

「ChatGPTに自分の主張を裏付けるリンクを探させてる」ってのが見え見えだ。

うちもそうだよ。そして、ああ、めちゃくちゃだよ。ほとんどの場合うまくいくけど、実際には全然信頼できない。他のツールはアクセスできないか、完全にドロップしてしまう。

名前空間と型の議論は納得できなかったけど、ENV変数がどこにあるのか、存在すること（そして理想的には何をするのか、どんなユースケースなのか）を追跡できるのは便利だと思う。ユーザーがどこにあるかを知らずに変数をオーバーライドする場合を見るとかね。あと、デフォルトのENV変数には、その使い方を示す簡単なコマンドラインの方法が必要だと思う。例えば、

use_of TZ

と入力したら、こう表示されるべき。

"誰かさんがTZはタイムゾーンに必要だって考えたんだ。適当な値を設定するとプログラムが壊れる可能性があるよ。"

みたいな。現状、こういうインタラクティブな機能がなくて、manページとかに頼らないといけないと思う。