あらすじ
ベータテスト以降、MRUクラウド上に1 TBの空き領域があることはよく知られています。 ボリュームは今日の基準でまともです-しかし、それをどうするか？ 写真や動画をそのようにアップロードしたくありません-アカウントハッキングは頻繁に発生し、いずれの場合もクラウドはクラウドであり、クラウドストレージは商用の会社に属しているという単純な事実を無視することはできません。自己利益。 そのため、たとえばEncFSなどの追加の保護層が必要です。 ハブとgithubに目を通すと、クラウド内のデータを暗号化する決定が下されているようです。 しかし、元の記事には記載されていない、明らかではないが非常に重要な不都合があります。同期するには、600GBの暗号化された写真をローカルに保存する必要があります 。 暗号化されていない600GBの写真がほとんど収まらない控えめなローカルストレージの場合、これは大きすぎます。
アイデア
したがって、野心的な計画が考案されました-クラウド用のFUSEファイルシステムを作成し、その上にEncFSをマウントします（セキュリティを強化するには、GPGキーを生成し、ecryptfsを使用する必要があります。最新のコンピューター機能によりEncFSをクラックできるためです）。 ある意味では、MEGAクラウドを使用してブラウザウィンドウにファイルをドラッグアンドドロップするようなものです。E2E暗号化が適用され、ローカルに何も占有せずにファイルがクラウドに送信されます。 名前は「MARC-FS」（MAail.Ru Cloud FileSystem）によって決定されました。 その助けを借りて、暗号化されたデータのローカルストレージの問題を回避します。データをEncFSディレクトリにコピーすることで、自動的に暗号化してクラウドに送信します。 実際、下位レベルでは、cp-> kernel FUSE module-> userspace libfuse hook-> EncFS-> FUSE kernel-> libfuse hook-> MARC-FS-> kernel network stackの形式のかなり長い変換チェーンを呼び出しますが、作業スキームは単純化されています次のようになります。
+---------------+ | | | Local data | | | | /media/DATA/ | | | +---------------+ | | | | +-------v-------+ | | | EncFS | | | | ~/remote-enc | | | +---------------+ | | FUSE | encryption | +-------v-------+ | | | MARC-FS | | | | ~/remote | | | +---------------+ | | FUSE | networking | +-------v-------+ | | | | | cloud.mail.ru | | | | | +---------------+
実装
計画は野心的ですが、実際には、FUSEとカーネルの両方の側面とクラウドの側面の両方から多くの制限に直面しなければなりませんでした。 おそらく、最も気がかりなのは、クラウドがデータ重複排除を使用していることです。 つまり、同じハッシュとサイズを持つファイルはいくつかの共通プールに保存され、ユーザーはダウンロード後に「ハードリンク」をアップロードするだけです。 もちろん、暗号化されたファイルは一意です。 キーによって保護されているため、Mail.ruがこのような個人用クラウドに注意を払わず、これについて苦情を申し立てないという懸念があります。 願わくば、Mail.ruのベータテストを敢行したOS X / Linuxのユーザーがあまりいないことを願っています。
その他の興味深い詳細：
- クラウドは
Transfer-Encoding: chunked
ダウンロードをサポートしていません。また、FUSEインターフェースでは、書き込み前にファイルサイズを事前に確認する方法はありません。 最初にファイルをメモリにロードする必要があります。次に、サイズを知ってからネットワーク経由で送信します。 - EncFSは、ファイルを断片に分割し、後で暗号化するため、その作業にはランダムな読み取り/書き込みが必要です。 ネットワークファイルシステム（NFSなど）の場合、プロトコルには「ファイルの先頭からこのオフセットに4096バイトを書き込む」などの命令が含まれていないため、これは恐怖と恐怖です。 したがって、EncFSを正しく動作させるには、作業中にファイルをメモリ内に保持する必要があります（ やがて 、中間データを保存するキャッシュディレクトリを指定する機能を追加しました。詳細については、リポジトリのREADME.mdを参照してください-著者のメモ）。
- クラウドとの接続はhttpsを介して確立されます。これにより、突然、かなり大きなメモリオーバーヘッドが追加され、SSLエンジンが初期化されます。 さらに、これに対処する方法は明確ではなく、他のネットワークファイルシステムもこれに遭遇します。
- ストレージとテラバイトのサイズですが、クラウドでは1つのリクエスト（2 GB）でアップロードされるファイルのサイズに制限があり、有料サービスのみがそれ以上のアップロードを可能にします。 写真や音楽のライブラリに適していますが、HDフィルムのコレクションをアップロードできません。後で透明なファイルの分割を追加しました。2GBを超えるファイルをアップロードまたはダウンロードすると、FSが壊れたり接着したりします。
- MacOSはLinuxとは異なるファイル記述子の多重化を使用するため、
libfuse
に存在するosxfuse
ではなく、Homebrew Caskを使用してosxfuse
たlibfuse
プロジェクトをリンクする必要がありました。 適切な回避策が含まれています。 また、発生する可能性のある問題のうち、MacOSでFUSEファイルシステムを別のFUSEファイルシステムにマウントすることは、再帰の問題によりデフォルトで無効になっていますが、これは手動でマウントオプションを使用してバイパスされます。
その結果（そしてそれにもかかわらず）、実行可能なオプションが得られ、その助けを借りて、音楽と写真のコレクション全体を埋めることができました とアニメ 暗号化されたファイルとしてクラウドに。 MARC-FSでの作業の結果をここに示します。ここでは、EncFSでバンドルをセットアップするための手順も見つけることができます。 作業は進行中であり、改善の前線は広く、プルリクエストと提案はもちろん歓迎します。
暗号化されたディレクトリの例：
ローカルで復号化：
クラウド上：
いくつかのメモ
Cloud APIの説明を見つけることができませんでした。関連する記事やプロジェクトからそれを引き出す必要がありました。 しかし、Mail.Ruに敬意を払う必要があります。25スレッドと1秒あたり数百のgetattr / read / write要求で作業している場合でも、500内部サーバーエラーのみが応答でスキップすることがあります。 あまり頻繁に会うことはありませんが、クラウドチームの誰かがこの記事を読んで詳細が必要な場合は、これらのレポートのいくつかを入手できます。
libfuseはファイルシステムを記述し、実際にはそのコンセプトのFUSEアーキテクチャは、たとえばGNU / HurdやPlan 9 From Bell Labsのユーザー空間クライアントサーバードライバーを思い出させました 。 これらのシステムの関連性が失われたために捨てられていた興味深いアイデアが、新しい命を受けたのは嬉しいことです。
FSのマルチスレッド化はゼロからひざまずきで発明する必要があったため、これは興味深い課題でした。 すべてが最良の方法で（そしてバグなしで）判明したという明確な確実性はありませんが、動作します-そして、それは非常に迅速に動作します。 クラウド自体がファイルの同時アップロードとダウンロードにどのように関連するかについて疑いがない限り。
Mac OS XでMARC-FSを詳細にテストしなかったことに注意する必要があります。私の友人と私は安定したビルドを達成し、端末で数回音楽をコピーしましたが、それ以上はしません。 アップルアイアンは手元にないので、FSの動作を効果的にテストすることはできません。だから、誰かがこのプラットフォームでFSの動作をサポートできるなら、嬉しいです。
免責事項
私がコードとこの記事を公開するのは、それらが誰かのために役立つことを望んでいますが、プレゼンテーションや使用の適合性を保証するものではありません。 クラウドの内部APIは随時変更される可能性があり、トラフになる可能性はかなり高くなります。 ご自身の責任で使用してください。
ライセンス契約Mail.Ruには、自動的な対話手段の禁止に関する行があることを知っていますが、legal_depの誰も私の質問を手紙で理解できず、状況を客観的に明確にすることができません。 最終的に、私たちはすべて、Mail.ruと同じように対話する電子メールクライアントを使用します。 私は2回D. A.にリダイレクトされました。A。は、法的なアドバイスは彼の道ではないと正直に答えました。
参照資料
PSファイルシステムを書くことで起こりうる結果について私に警告する前に- 私はすでに知っています。