https://social.treehouse.systems/@thesamesam/116662824873341...

皮肉なことに、Postfixはデフォルトインストールでroot/RCEの記録がないけど、opensmptdにはある(CVE-2020-7247)。今後どうなるかは時間が教えてくれるだろうね。

excludeは自動化ジョブで大きなgitリポジトリや他の大きなファイルを重複させないために非常によく使われる。これがあると多くの人にとっては致命的な問題になると思う。

Postfixについてどこにそれが書いてあるの？リンクを辿ったけど、見えるのはAIがバグを見つけるために使われてるだけで、コードを書くためじゃないよね。

クロードって名前の人には申し訳ない気持ちになる。

ありがとう！TridgeがClaudeを使ってるなんて知らなかった。これからはOpenrsyncを使うことにするよ。

あなたの引用の上から: > 公式にサポートされているオペレーティングシステムはOpenBSDだけで、これはかなりのセキュリティ機能を持っている。あなたの引用の下から: > これはFreeBSDのCapsicumで可能だと思うけど、Linuxのセキュリティ機能はめちゃくちゃで、適切にセキュリティを確保するには専門家の手が必要だよ。コンパイルして動くという意味ではポータブルだけど、同じセキュリティ機能を持っているわけではない。Linuxの（アップストリームの）上でpledge/unveilを見てみたいけど、期待はしてないよ。

その引用はちょっと単純化しすぎてて、完全に間違ってると思う。> それがないと、あなたのシステムは公共のネットワークから任意のデータを受け入れる。これらの機能は、公共のネットワークから任意のデータを受け入れる場合でも変わらないよ。彼らは、悪用されたプロセスができることを制限するんだ。『セキュリティ』セクションでちゃんと説明されてるから、これがどこから来たのかは分からないな。

Linuxにはpledgeやunveil、capsicumみたいな機能はないよ。cgroupsやnamespaces、他にもいろいろなものを組み合わせて似たようなことをしようとする必要がある。最初から「サンドボックス」や能力の制限を形成するために、いろんなシステムが相互作用して組み合わさる形で作られてきたから、特定のシステムコールやカーネルパスで実現するような完全な隔離とは違うんだ。最近はlandlockについてのコメントも見かけるけど、あれは新しいものを作るんじゃなくて、Linuxのプリミティブを再利用するんじゃないかな。まあ、これは完全な推測だけど、新しいものを作るより再利用する方が論理的だと思う。「めちゃくちゃ」って言ってるのは、いろんな方法があって、どれがベストか選ぶのが難しいってことだと思う。いろんなサブシステムを徹底的に調べないといけないからね。（1つか2つの比較的シンプルなシステムコールだけじゃないから）

いや、だからほとんど誰も厳格な信頼の境界の外でそれを使わないんだ。このセキュリティセクションは、rsyncがcurlみたいに敵対的な相手とやり取りするならもっと意味があると思う。もしrsyncの相手が敵対的なら、もっと大きな問題があるかもね！俺は違うと思う。rsyncは「友好的」なシステム間でデータを転送するために最もよく使われるけど、実際にはセキュリティの境界を越えているんだ。攻撃者がそれを利用して一つのシステムの侵害を複数のシステムの侵害に変えることができないようにすることが重要だよ。

ほとんど誰も厳格な信頼の境界の外でそれを使わない。 「厳格」をどう定義するかは自由だけど、10年前に見た限りでは、ほとんどのLinuxディストリビューションはrsyncでミラーリングを扱ってたよ。それってオープンソースエコシステムのかなりコアな部分での多くの使用例だね。

15.0だったかな？15.xラインのマイナーポイントリリースのどれかで出た気がするし、いくつかのスクリプトが謎に壊れたのを覚えてる。追記: ああ、面白いことに、15.0に含まれてたけど、後方互換性を壊す変更は15.4に回されたんだね。 https://apple.stackexchange.com/a/479297

基本的にはGNU Tar/CPIOとBSD Tar/CPIOみたいな感じだね。僕はほとんどどこでもBSDバリアントを使うように標準化してるよ（特に今はWindowsでも搭載されていて、tarコマンドで他のアーカイブ形式も扱えるから）。でも、どこにでもインストールするのは本当に面倒だね。

他のBSDユーティリティ（SysVユーティリティを使ってるならそっちも）とGNUのものが違うのと、全く変わらないよ。もう50年もこれに慣れてるからね。

これを止める唯一の方法は、元の著者がBSDライセンスでリリースすることだね。それで止まるのかな？私の理解では、少なくともOpenBSDはライセンスだけじゃなくて技術的な理由で物事をやり直す傾向があるみたい。

AppleやAndroidはそれを好むだろうね。これを読んで思ったのは、なんでAppleやAndroidがrsyncをわざわざ含めるんだろう？DebianやFreeBSDの新規インストールでは手動でインストールしなきゃいけなかったことに気づいたんだけど、最近あまり使ってないMacをチェックしたら、ちゃんとインストールされてた。

すでに宛先に/tmp/servicesディレクトリがあったのかな？rsyncでよくある混乱の一つは、ディレクトリとトレーリングスラッシュの扱いなんだよね。

openrsyncがリモートファイル/tmp/servicesを作成すると思ってたんだけど、実際には/tmp/services/servicesができちゃった。rsyncに何年も苦しめられた身として、その気持ちはわかるけど、2つ目の「services」を作る方がずっと理にかなってるし、安全なデフォルトだと思う。rsyncのデフォルトをもう少し常識的なものに変えて、未来の世代をこの混乱から救えるチャンスがあるなら、やるべきだと思う。