Kích thước tên tệp (và thư mục) tối đa được phép với eCryptfs là bao nhiêu?


44

Tôi là người dùng eCryptfs mới và tôi có một câu hỏi rất cơ bản mà tôi không thể tìm thấy ở bất cứ đâu. Tôi quan tâm đến việc sử dụng eCryptfs thông qua NAS Synology sử dụng Linux.

Trong khi thử mã hóa thư mục của tôi (EXT4) thông qua ứng dụng mã hóa của Synology (eCryptfs), tôi gặp phải các lỗi cho biết độ dài tên tệp của tôi không thể vượt quá 45 ký tự (vì vậy, không mã hóa).

Nếu giới hạn thực sự là 45 ký tự, eCryptfs có thể không phải là một công cụ có thể sử dụng được cho hầu hết.

Kích thước tên tệp tối đa được phép khi mã hóa tệp và thư mục bằng eCryptfs là bao nhiêu? Là Linux 255 ký tự?


6
Imho cách ecryptfs không mã hóa tên tập tin là vô lý. Đầu tiên, nó cung cấp hơn 20 byte bằng cách thêm vào một chuỗi cố định "ECRYPTFS_FNEK_ENCRYPTED." đến từng tên tệp. Sau đó, nó thực hiện trước quá nhiều byte ngẫu nhiên để làm cho các tên giống nhau trông khác nhau. EncFS thực hiện điều đó theo cách hiệu quả hơn nhiều.

Câu trả lời:


70

Tiết lộ đầy đủ: Tôi là một trong những tác giả và người duy trì hiện tại của các tiện ích không gian người dùng eCryptfs.

Câu hỏi tuyệt vời!

Linux có độ dài tên tệp tối đa là 255 ký tự cho hầu hết các hệ thống tệp (bao gồm EXT4) và đường dẫn tối đa 4096 ký tự.

eCryptfs là một hệ thống tập tin lớp. Nó xếp chồng lên trên một hệ thống tập tin khác như EXT4, thực sự được sử dụng để ghi dữ liệu vào đĩa. eCryptfs luôn mã hóa nội dung tệp, nhưng nó có thể tùy chọn mã hóa tên tệp (che khuất) (hoặc không).

Nếu tên tệp không được mã hóa, thì bạn có thể viết tên tệp tối đa 255 ký tự và mã hóa nội dung của chúng một cách an toàn, vì tên tệp được ghi vào hệ thống tệp thấp hơn sẽ khớp một cách đơn giản. Mặc dù kẻ tấn công sẽ không thể đọc nội dung của index.htmlhoặc budget.xls, nhưng chúng sẽ biết tên tệp nào tồn tại. Điều đó có thể (hoặc có thể không) rò rỉ thông tin nhạy cảm tùy thuộc vào trường hợp sử dụng của bạn.

Nếu tên tệp được mã hóa, mọi thứ sẽ phức tạp hơn một chút. eCryptfs chuẩn bị một chút dữ liệu ở mặt trước của tên tệp được mã hóa, sao cho nó có thể xác định tên tệp được mã hóa một cách dứt khoát. Ngoài ra, bản thân mã hóa liên quan đến việc "đệm" tên tệp.

Ví dụ, tôi có một tệp được mã hóa , ~/.bashrc. Tên tệp này được mã hóa bằng khóa của tôi để:

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

Rõ ràng, tên tệp 7 ký tự đó hiện yêu cầu nhiều hơn 7 ký tự được mã hóa. Theo kinh nghiệm, chúng tôi đã thấy rằng tên tệp ký tự dài hơn 143 ký tự bắt đầu yêu cầu> 255 ký tự để mã hóa. Vì vậy, chúng tôi (với tư cách là nhà phát triển ngược dòng eCryptfs) thường khuyên bạn nên giới hạn tên tệp của mình ở mức ~ 140 ký tự.

Bây giờ, tất cả những gì đã nói, NAS Synology là một sản phẩm thương mại nhúng và sử dụng eCryptfs và Linux để mã hóa và bảo mật dữ liệu trên thiết bị. Chúng tôi (các nhà phát triển ngược dòng của eCryptfs) không liên quan gì đến Synology hoặc các sản phẩm của họ, mặc dù chúng tôi thường rất vui khi thấy eCryptfs được sử dụng ngoài tự nhiên . Dường như với tôi rằng đề xuất 45 ký tự của họ là một lỗi đánh máy (từ khuyến nghị 140 ký tự của chúng tôi), hoặc đơn giản là một ước tính bảo thủ hơn nhiều.


Tôi thực sự rất thích nhìn thấy, hệ thống tập tin lớp phủ FUSE giải quyết "tên tệp quá dài" của riêng nó và phần còn lại chỉ là proxy 1: 1 với hệ thống tập tin lót. Các fUSE FUSE như vậy sẽ hữu ích cho các hệ thống tệp khác nhau (ecryptfs, EncFS), trong khi đối với tên tệp hiện được hỗ trợ sẽ không thay đổi gì. Và một lần nữa, sẽ là tùy chọn. - Mong muốn của tôi: unix.stackexchange.com/q/283149/9689
Grzegorz Wierzowiecki

17
Câu trả lời này không hoàn toàn chính xác. Kích thước tối đa của tên tệp là các loại char 255 Byte hoặc C / C ++. Nhưng các ký tự tối đa trong một tên tệp khác nhau. Khi sử dụng UTF-8, mặc định cho hầu hết các hệ thống, tên tệp có thể nằm trong khoảng 63-255 ký tự (còn gọi là Mã điểm), nếu sử dụng UTF-16, 63-127. Điều quan trọng cần lưu ý, 1 ký tự có thể là một hoặc nhiều byte trong không gian lưu trữ và phụ thuộc vào bộ mã mà người dùng hệ thống đang sử dụng.
Rahly

Gợi ý cho nhà phát triển: Phân tách tên được mã hóa giữa các thư mục con được ẩn khỏi người dùng cuối để có được độ dài cần thiết, thậm chí có thể vượt quá giới hạn độ dài tên tối đa của linux nếu hệ thống tệp bên ngoài cần. Một tệp hoặc thư mục trở thành "ENCRYPTFS-01-OF-04 [.....] / ENCRYPTFS-02-OF-04 [.....] / ENCRYPTFS-03-OF-04 [..... ] / ENCRYPTFS-04-OF-04 [.....] "- Linux btrfs, ext1-4 và các loại khác không có độ sâu thư mục được xác định tối đa để hệ thống tệp có thể xử lý mở rộng tên tệp và thư mục qua nhiều thư mục con không được hiển thị như thế này .
Dale Mahalko

1
Đề nghị của tôi sẽ là lưu trữ bất kỳ siêu dữ liệu nào bạn đang lưu trữ trong xattrs, thay vì trong tên tệp. : |
Trejkaz

1
Bạn nói rằng eCryptfs "có thể tùy chọn mã hóa tên tệp (tối nghĩa) (hoặc không)." Làm cách nào để tắt mã hóa tên tệp để tôi có thể lấy lại tên tệp 255-char đầy đủ thay vì bị giới hạn ở 143 ký tự? Nhân tiện, tôi tin rằng cách tôi đã cài đặt eCryptfs bằng cách kiểm tra hộp hoặc bất cứ thứ gì cho "Thư mục nhà được mã hóa" trong quá trình cài đặt Ubuntu của tôi.
Gabriel Staples

11

Chủ đề này rất thú vị bởi vì tôi đã tự hỏi điều tương tự chính xác. Tôi có thể sống với việc phải đổi tên 20 tệp trong số 50 000 nếu tên tệp cần từ 140 ký tự trở xuống, nhưng 45 hoặc ít hơn là không khả thi (trong tình huống của tôi) vì nó sẽ yêu cầu tôi đổi tên quá nhiều tệp.

Tôi đã hỏi chính xác câu hỏi tương tự trực tiếp với Synology (thậm chí chỉ chúng cho bài viết hiện tại) và câu trả lời của họ rất thú vị: "Giới hạn tên tệp chia sẻ được mã hóa là 143 byte. Nó có thể lên tới 140 ký tự Latin thuần túy hoặc 45 CJK (tiếng Trung Quốc , Nhân vật Nhật Bản và Hàn Quốc). "

Theo câu trả lời này, tôi đã tự kiểm tra nhiều hơn, thử nghiệm với các tệp có 45, 46, 140, 143 và 144 ký tự. Các thử nghiệm của tôi cho thấy các tệp có tối đa 143 ký tự (không phải byte, trái với những gì Synology đã nói với tôi) sẽ được mã hóa, nhưng các tệp có 144 ký tự sẽ TRƯỚC một thư mục sẽ được mã hóa. Tuy nhiên, THÔNG ĐIỆP LRI mà tôi nhận được từ NAS của mình là tên tệp cần ít hơn 45 ký tự (trong khi thực tế là nó phải nhỏ hơn 144 ký tự).

Tôi đã không làm các bài kiểm tra với các ký tự CJK ... Nhưng, với bất kỳ ai đọc nó, có vẻ như bạn vẫn ổn cho đến 143 ký tự, bất chấp những gì hệ thống nói với bạn.


7

Tôi muốn làm rõ, linux có giới hạn 255 byte cho mỗi tên tệp, không phải 255 ký tự. Đây là một sự khác biệt đáng kể và nếu bạn sử dụng mã hóa UTF-8, bạn có thể kết thúc với tên tệp tối đa 100 ký tự.


1
63 là mức tối đa nếu mỗi ký tự sử dụng mã hóa tối đa 4 byte cho mỗi điểm mã. Điều này giống với bất kỳ lược đồ UTF nào (UTF-16 và UTF-32)
Rahly

@Rahly Điều đó cuối cùng có thể thay đổi. Trước khi điểm mã Unicode hợp lệ tối đa được giảm xuống để U+10FFFFđáp ứng các giới hạn của UCS-2 (về cơ bản là UTF-16 không có cặp thay thế), UTF-8 có thể yêu cầu tối đa 6 byte để thể hiện điểm mã 32 bit vì cách mã hóa "Bắt đầu ký tự" và "tiếp tục ký tự" để đảm bảo rằng có thể lấy lại đồng bộ hóa trình phân tích cú pháp bất kể bạn bắt đầu phân tích cú pháp trong một luồng byte ở đâu. Luôn có khả năng là cuối cùng họ sẽ quyết định đảo ngược quyết định đó vì họ sắp hết các điểm mã chưa được gán.
ssokolow

1
Nhưng rất khó xảy ra, trừ khi họ bắt đầu thêm các nhân vật như điên. Kể từ U8.0, chỉ có 120k được chỉ định. Họ đã thêm ~ 8k ký tự trong lần lặp này. Nếu họ tiếp tục, nó sẽ cần mở rộng ở phiên bản ~ 106.
Rahly

Và tôi nghĩ rằng họ cũng phải loại bỏ Windows một JavaScript, vì cả hai đều dựa vào UTF-16. (Tuy nhiên, thể khắc phục điều này trong trường hợp của JavaScript?)
SamB

1

Độ dài tên tệp của mã hóa chỉ là một vấn đề đối với tôi vì tôi cần một cây con cụ thể của thư mục nhà để hỗ trợ tên tệp dài và cuối cùng tôi nhận ra rằng tôi có thể chỉ cần tạo một hệ thống tệp trong tệp và gắn kết:

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

Có thể có tất cả các loại vấn đề hiệu quả với điều này, nhưng nó đủ cho trường hợp của tôi khi các tệp chỉ là kết quả kiểm tra được tạo theo định kỳ cho mục đích địa phương của riêng tôi.

Các đồng nghiệp của tôi đã đưa hình ảnh của họ vào / tmp - dữ liệu thử nghiệm không đặc biệt bí mật: chúng tôi chủ yếu muốn bảo mật mã nguồn của mình chứ không phải kết quả thử nghiệm.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.