Làm thế nào để tôi đệ quy cắt toàn bộ cây thư mục?


47

Tôi có một cây thư mục mà tôi muốn cắt nhỏ với tiện ích 'shred' của Linux. Thật không may, shred không có -Rtùy chọn cho việc băm đệ quy.

Làm thế nào tôi có thể cắt toàn bộ cây thư mục theo cách đệ quy?

Câu trả lời:


45

Sử dụng findlệnh để thực hiện shredđệ quy:

find <dir> -type f -exec shred {} \;

Nó hoạt động mà không có tùy chọn -depth? Nó hoạt động trên các hệ thống tập tin nhật ký hiện đại?
người dùng không xác định

@userunknown Không, shred không hoạt động trên các hệ thống tệp nhật ký hiện đại. Để biết thêm thông tin chính xác, xin vui lòng xem man shred.
FanaticD

Cũng lưu ý rằng phương pháp này thậm chí sẽ không xóa tên tệp , vì vậy mọi dữ liệu được lưu trữ như thế này chắc chắn sẽ bị bỏ lại ( srmtừ câu trả lời của @ Cookie ít nhất sẽ cố gắng khắc phục vấn đề này).
ntninja

Sử dụng -exec shred {} +để làm cho nó nhanh hơn vì shred chấp nhận nhiều đối số.
Sumit

28

Coi chừng vụn!

Từ trang shred-manpage:

THẬN TRỌNG: Lưu ý rằng shred phụ thuộc vào một giả định rất quan trọng: hệ thống tệp ghi đè dữ liệu tại chỗ. Đây là cách truyền thống để làm mọi thứ, nhưng nhiều thiết kế hệ thống tệp hiện đại không đáp ứng giả định này. Sau đây là các ví dụ về hệ thống tệp mà shred không hiệu quả hoặc không được đảm bảo có hiệu lực trong tất cả các chế độ hệ thống tệp:

  • các hệ thống tệp được cấu trúc hoặc ghi nhật ký, chẳng hạn như các hệ thống được cung cấp với AIX và Solaris (và JFS, ReiserFS, XFS, Ext3, v.v.)

  • hệ thống tệp ghi dữ liệu dư thừa và tiếp tục ngay cả khi một số lần ghi bị lỗi, chẳng hạn như hệ thống tệp dựa trên RAID

  • hệ thống tệp tạo ảnh chụp nhanh, chẳng hạn như máy chủ NFS của Thiết bị Mạng

  • hệ thống tệp lưu trữ trong các vị trí tạm thời, chẳng hạn như máy khách NFS phiên bản 3

  • hệ thống tập tin nén

Trong trường hợp hệ thống tệp ext3, từ chối trách nhiệm ở trên áp dụng (và shred vì thế có hiệu lực hạn chế) chỉ trong chế độ data = tạp chí, trong đó ghi lại dữ liệu tệp ngoài siêu dữ liệu. Trong cả hai chế độ data = order (mặc định) và data = writBack, shred hoạt động như bình thường. Có thể thay đổi chế độ ghi nhật ký Ext3 bằng cách thêm tùy chọn data = Something vào tùy chọn gắn kết cho một hệ thống tệp cụ thể trong tệp / etc / fstab, như được ghi lại trong trang man mount (man mount).

Ngoài ra, sao lưu hệ thống tệp và máy nhân bản từ xa có thể chứa các bản sao của tệp không thể xóa và điều đó sẽ cho phép khôi phục tệp được băm nhỏ sau đó.

Giải pháp: Sử dụng hệ thống tệp được mã hóa và chỉ cần xóa các tệp của bạn.


+1 cho con trỏ trên shred, tôi đã có một trường hợp tương tự trước đây. Nó không hoạt động trên NFS của NetApp. NetApp sử dụng WAFL và sử dụng copy-on-write bao gồm cả metajournalling, vì vậy nó đúng. Ngoài ra với ZFS mới nhất của Solaris là một trường hợp khác mà shred đổ ra.
Nikhil Mulley

6
Đây là một giải pháp tồi. Một hệ thống tập tin được mã hóa chỉ an toàn miễn là nó bị khóa (và vì vậy không thể đếm được). Ngay khi hệ điều hành của bạn hoạt động, dữ liệu sẽ được cập nhật.
oleks

3
@oleks: Cả việc sử dụng shredvà mã hóa dữ liệu ngăn chặn đọc dữ liệu ra khỏi thiết bị lưu trữ ẩn (nghĩ trộm cắp hoặc cảnh sát) với mã hóa dữ liệu có thêm lợi ích của việc bảo vệ tất cả các file, không chỉ những người (đúng) xóa. Khi hệ thống tệp được gắn kết, chúng tôi sẽ trở lại các quyền unix tốt trong cả hai trường hợp và bảo vệ dữ liệu trở thành nhiệm vụ bảo mật hệ điều hành và quản trị hệ thống phù hợp một lần nữa. Mã hóa hệ thống tập tin trả trước chắc chắn không tệ hơn trong việc bảo vệ dữ liệu khi nghỉ ngơi so với việc sử dụng chiến lược shred!
ntninja

12

Sử dụng xóa an toàn thay thế.

sudo apt-get install secure-delete
srm -r pathname

Làm xong. Xóa an toàn là hoang tưởng hơn nhiều so với shred, sử dụng 38 đường chuyền thay vì 3. Để thực hiện một lượt nhanh, sử dụng

srm -rfll pathname

fll giúp bạn có một trình tạo dữ liệu ít ngẫu nhiên hơn và chỉ một lần duy nhất.


Nó có giải quyết được vấn đề được đề cập trong unix.stackexchange.com/a/27075/18886 không?
Ian Dunn

Làm thế nào nó có thể? Không
Cookie

Lưu ý rằng phương pháp này có lợi ích bổ sung so với các findphương pháp dựa trên đề xuất sẽ cố gắng xóa tên tệp được lưu trữ bằng cách đổi tên tệp trước khi cắt và hủy liên kết chúng.
ntninja

Các phương thức dựa trên tìm kiếm @ntninja sử dụng shred và shred không đổi tên các tập tin trước khi hoàn thiện để xóa chúng. Vậy lợi ích như nhau phải không?
tuxayo

11

Kết hợp câu trả lời này với các tùy chọn được biết đến tốt nhất để cắt nhỏ bằng liên kết tràn ngăn xếp này ' Xóa tệp vĩnh viễn và an toàn trên CentOS ':

find <directory> -depth -type f -exec shred -v -n 1 -z -u {} \;

Chỉnh sửa: Lưu ý rằng câu trả lời tốt nhất cho việc băm nhỏ một tệp sẽ buộc đồng bộ hóa ghi thay đổi vào phương tiện trước khi xóa tệp vì một số hoặc tất cả các hệ thống tệp được ghi có bộ đệm.

Nếu có thể, lệnh find sẽ gọi một tập lệnh shell trên tệp chạy:

shred -v -n 1 /path/to/your/file #overwriting with random data
sync #forcing a sync of the buffers to the disk
shred -v -n 0 -z -u /path/to/your/file #overwriting with zeroes and remove the file

trên mỗi tập tin.


Sau khi đọc và nghiên cứu nhiều câu trả lời, tôi thấy (imho) câu trả lời này là kỹ lưỡng nhất. Tôi chỉ nói thêm rằng vì shred không xóa các thư mục mà tôi đã thêm vào rm -rvf $1tập lệnh shell (trong đó $ 1 là tập tin / path / to / your / được chuyển từ bản {}mở rộng trong find... -exec)
JoelAZ

4
shred đã thực hiện fsync (2) sau mỗi lần vượt qua. Chính xác bởi vì bạn cần buộc các thay đổi tệp để đến đĩa trước khi vượt qua tiếp theo.
Ángel

Làm gì depthở đây? Cũng không chắc chắn về dấu gạch chéo ngược
genorama

5
find /your/directory -exec shred {} \;

Ủng hộ, nhưng James đánh bại bạn một phút để chấp nhận.
Steve V.

Nó hoạt động mà không có tùy chọn -depth? Nó hoạt động trên các hệ thống tập tin nhật ký hiện đại?
người dùng không xác định

3
find [dirname] -depth -type f -exec shred -n1 {} \;

Điều này thực hiện tìm kiếm theo chiều sâu cho các tệp trong thư mục [dirname], sau đó chạy shred -n1lệnh trên mỗi tệp. Khi xóa tệp và / hoặc thư mục, thêm vào -depthnhư mặc định là một thói quen tốt, mặc dù nó không thực sự cần thiết cho trường hợp này. Khi chạy loại lệnh này rm -rfthay vì shred, -depthcần thiết để đảm bảo rằng các thư mục không bị xóa trước khi nội dung của các thư mục được cố gắng xóa (do đó gây ra lỗi).


3
Bạn nên sử dụng shred -N 1, vì mặc định, băm nhỏ 3 lần, là dầu rắn. Một lần là đủ, hoặc 30 lần sẽ không hoạt động.
người dùng không xác định

Cung cấp một lệnh đơn giản như một câu trả lời không phải là cách tốt nhất để trả lời một câu hỏi. Tôi sẽ khuyên bạn nên thêm một lời giải thích nhỏ về những gì dòng đang làm và những hạn chế có thể có liên quan đến việc sử dụng nó.
n0pe

0

shredPhương pháp kỹ lưỡng nhất mà tôi đã tìm thấy, bao gồm cả loại bỏ thư mục, là findgọi một tập lệnh để có shred:

  • ghi đè tập tin
  • đồng bộ hóa
  • sau đó xóa
  • và cuối cùng gọi rm để xóa tên thư mục.

Phương pháp này cũng xử lý đúng tên tệp có khoảng trắng trong đó.

Đầu tiên - shredtập lệnh (Tôi đã đặt tên cho tôi dirShredder.shvà lưu nó trong /rootthư mục:

shred -v -n 1 "$1" #overwriting with random data
sync #forcing a sync of the buffers to the disk
shred -v -n 0 -z -u "$1" #overwriting with zeroes and remove the file
rm -rvf "$1" # call rm to remove the directories

Sau đó, gọi kịch bản như thế này:

find /volume1/pathToShred/ -mindepth 1 -depth -exec /root/dirShredder.sh "{}" \;

Hãy chắc chắn để đánh dấu killit.shtệp thực thi ( chmod +x) và tất nhiên cập nhật đường dẫn cho thư mục bạn muốn cắt nhỏ và dirShredder.shnếu bạn lưu trữ nó ở một nơi khác.

NOTA BENE - shredcó vấn đề về hệ thống tệp Copy-on-Write (ZFS, BTRFS, et al) và thậm chí trên các hệ thống tệp Nhật ký. Không có cách "tốt nhất" nào được chấp nhận thực sự để giải quyết vấn đề này mà tôi đã tìm thấy ngoài "hệ thống tập tin được mã hóa" nhưng tôi không chắc chắn về hiệu quả của việc này sau thực tế.
Gần nhất có vẻ như bạn có thể nhận được là ghi đè lên tất cả không gian trống trên ổ đĩa với dữ liệu ngẫu nhiên sau khi ops của bạn (không phải số không, có vẻ như điều này không phải lúc nào cũng đáng tin cậy.) Ngoài ra, SSD cũng có thể có những cân nhắc khác (như TRIM.)

Tôi không đi sâu vào những vấn đề ở đây, chẳng hạn có câu trả lời Stack khác (ví dụ câu trả lời của @user trong câu hỏi này) và rất nhiều cuộc thảo luận trên mạng 'bao gồm các chủ đề này để tìm kiếm chúng nếu bạn cần mức độ bảo mật đó.

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.