eCryptfsで許可されるファイル名(およびフォルダー)の最大サイズは?


44

私は新しいeCryptfsユーザーであり、どこにも見つからない非常に基本的な質問があります。Linuxを使用するSynology NAS経由でeCryptfsを使用することに興味があります。

Synologyの暗号化アプリ(eCryptfs)でフォルダー(EXT4)を暗号化しようとすると、ファイル名の長さが45文字を超えない(暗号化なし)というエラーが発生します。

制限が実際に45文字である場合、eCryptfsはほとんどの場合に使用できるツールではない可能性があります。

eCryptfsを使用してファイルとフォルダーを暗号化する場合の最大許容ファイル名サイズは?Linuxは255文字ですか?


6
ecryptfsがファイル名を暗号化する方法は、まったくばかげています。まず、固定文字列「ECRYPTFS_FNEK_ENCRYPTED」を先頭に追加することにより、20バイト以上を解放します。各ファイル名に。それから、同じ名前が異なって見えるように、あまりにも多くのランダムなバイトを前に付けます。EncFSはそれをはるかに効率的な方法で行います。

回答:


70

完全な開示:私はeCryptfsユーザースペースユーティリティの作成者の1人であり、現在のメンテナーです。

いい質問です!

Linuxのファイル名の最大長は、ほとんどのファイルシステム(EXT4を含む)で255文字、パスの最大長は4096文字です。

eCryptfsは階層化されたファイルシステムです。実際にディスクにデータを書き込むために使用されるEXT4などの別のファイルシステムの上にスタックします。eCryptfsは常にファイルの内容を暗号化しますが、オプションでファイル名を暗号化(不明瞭化)することもできます(しないこともできます)。

ファイル名が暗号化されていない場合は、下位のファイルシステムに書き込まれたファイル名が単純に一致するため、最大255文字のファイル名を安全に記述してその内容を暗号化できます。攻撃者は内容を読み取ることができないだろうがindex.htmlまたはbudget.xls、彼らはファイル名が存在するものを知っているだろう。ユースケースによっては、機密情報が漏洩する可能性があります(または漏洩しない場合があります)。

ファイル名が暗号化されている場合、少し複雑になります。eCryptfsは、暗号化されたファイル名の前に、暗号化されたファイル名を明確に識別できるように、少しのデータを付加します。また、暗号化自体にファイル名の「パディング」が含まれます。

たとえば、暗号化されたファイルがあります~/.bashrc。このファイル名は、私のキーを使用して暗号化されます:

/home/kirkland/.Private/ECRYPTFS_FNEK_ENCRYPTED.dWek2i3.WxXtwxzQdkM23hiYK757lNI7Ydf0xqZ1LpDovrdnruDb1-5l67.EU--

明らかに、その7文字のファイル名では、暗号化に7文字以上が必要になりました。経験的に、143文字を超える文字のファイル名では暗号化に255文字以上が必要になることがわかりました。そのため、(eCryptfsアップストリーム開発者として)通常、ファイル名を最大140文字に制限することをお勧めします。

今や、Synology NASは、eCryptfsとLinuxを埋め込み、使用してデバイス上のデータを暗号化および保護する商用製品です。私たち(eCryptfsのアップストリーム開発者)は、Synologyまたはその製品とは何の関係もありませんが、eCryptfsが実際に使用されているのを見て喜んでいます。45文字という推奨事項は、誤植(140文字の推奨事項から)であるか、単に控えめな推定値であるかのように思われます。


FUSEオーバーレイファイルシステムは、それ自体で「長すぎるファイル名」を解決し、アンダーレイファイルシステムと1対1のプロキシのみを解決することを本当に楽しみにしています。このようなFUSE fsは、さまざまなファイルシステム(ecryptfs、EncFS)で役立ちますが、現在サポートされているファイル名では何も変わりません。また、オプションです。-私の願い:unix.stackexchange.com/q/283​​149/9689
Grzegorz Wierzowiecki

17
この答えは完全に正しいわけではありません。ファイル名の最大サイズは255バイトまたはC / C ++ char型です。ただし、ファイル名の最大文字数は異なります。ほとんどのシステムのデフォルトであるUTF-8を使用する場合、UTF-16、63-127を使用する場合、ファイル名は63〜255文字(コードポイントとも呼ばれます)の間にすることができます。重要なのは、1文字はストレージスペースの1バイト以上であり、システムのユーザーが使用しているコードセットに依存することです。
ラーリー

開発者への提案:暗号化された名前をエンドユーザーから隠されたサブディレクトリに分割して、必要な長さを取得します。外部ファイルシステムで必要な場合は、Linuxの最大名前長制限を超える可能性があります。単一のファイルまたはディレクトリは、「ENCRYPTFS-01-OF-04 [.....] / ENCRYPTFS-02-OF-04 [.....] / ENCRYPTFS-03-OF-04 [..... ] / ENCRYPTFS-04-OF-04 [.....] "-Linux btrfs、ext1-4、およびその他には最大のディレクトリの深さが定義されていないため、ファイルシステムはこのような複数の非公開サブディレクトリにわたるファイル名とディレクトリ名の拡張を処理できます。
デールマハルコ16

1
私の提案は、ファイル名ではなくxattrsに保存しているメタデータを保存することでした。:|
トレカズ

1
eCryptfsは「オプションでファイル名を暗号化(不明瞭化)できる(またはしない)」と言います。ファイル名の暗号化を無効にして、143文字に制限されるのではなく、255文字の完全なファイル名を取得する方法を教えてください。ちなみに、eCryptfsをインストールする方法は、Ubuntuのインストールプロセス中に「暗号化されたホームディレクトリ」のチェックボックスなどをオンにすることでした。
ガブリエルステープルズ

11

私はまったく同じことを考えていたので、このスレッドは非常に興味深いです。ファイル名を140文字以下にする必要がある場合、50 000個のうち20個のファイルの名前を変更する必要がありますが、あまり多くのファイルの名前を変更する必要があるため、45文字以下は(私の状況では)実行不可能です。

私はまったく同じ質問をSynologyに直接尋ねましたが(現在の記事を指してさえ)、彼らの答えは興味深いものでした:「暗号化された共有のファイル名の制限は143バイトです。 、日本語、韓国語)文字。」

この回答に続いて、45、46、140、143、144文字のファイルでテストすることで、さらに自分自身をテストしました。私のテストでは、最大143文字のファイル(Synologyが教えてくれたバイトではなく)が暗号化されますが、144文字のファイルは暗号化されるフォルダーを防止します。ただし、NASから取得するエラーメッセージでは、ファイル名は45文字未満にする必要があります(実際には、144文字未満にする必要があります)。

私はCJK文字でテストをしませんでした...しかし、これを読んでいる人にとっては、システムがあなたに言っていることにもかかわらず、143文字までは大丈夫のようです。


7

Linuxには、255文字ではなく、ファイル名ごとに255バイトの制限があることを明確にしたいと思います。これは大きな違いであり、たとえばUTF-8エンコーディングを使用する場合、最大100文字のファイル名になる可能性があります。


1
すべての文字がコードポイントごとに4バイトの最大エンコードを使用する場合、63は最大です。これは、UTFスキーマ(UTF-16およびUTF-32)のいずれかのために同じである
Rahly

@Rahlyただし、最終的には変更される可能性があります。U+10FFFFUCS-2(基本的にサロゲートペアなしのUTF-16)の制限を満たすために最大有効Unicodeコードポイントが削減される前に、UTF-8はエンコード方法により32ビットコードポイントを表すために最大6バイトを必要とする可能性がありました「文字の開始」および「文字の継続」。バイトストリーム内のどこから解析を開始しても、パーサーの同期を再取得できるようにします。割り当てられていないコードポイントが不足しているため、最終的にその決定を取り消すことになる可能性が常にあります。
-ssokolow

1
しかし、マッドのようなキャラクターを追加し始めない限り、ほとんどありません。U8.0では、120kのみが割り当てられています。彼らはこの反復で〜8k文字を追加しました。彼らがそれを維持する場合、バージョン〜106で拡張する必要があります。
ラーリー

また、どちらもUTF-16に依存しているため、最初にWindowsからJavaScriptを削除する必要があると思います。(ただし、JavaScriptの場合、これを修正できる可能がありますか?)
SamB

1

ecryptのファイル名の長さは、長いファイル名をサポートするためにホームディレクトリの特定のサブツリーを必要とするという点で問題であり、最終的にファイル内にファイルシステムを作成してマウントできることに気付きました:

dd if=/dev/zero of=/home/me/.some.img bs=1024 count=1024
mkfs.ext3 /home/me/.some.img
chmod 777 /home/me/longfilenames
sudo mount /home/me/.some.img /home/me/longfilenames

おそらくこれにはあらゆる種類の効率の問題がありますが、ファイルが自分のローカル目的のために定期的に作成されたテスト結果であるという私の場合には十分です。

私の同僚はイメージを/ tmpに配置しました-テストデータは特に機密ではありません。テスト結果ではなく、主にソースコードを保護したいのです。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.