Làm cách nào để khắc phục lỗ hổng thiết kế NTFS Move / Copy?

31

Như bất kỳ ai đã xử lý các quyền của máy chủ tệp đều biết, NTFS có một tính năng / lỗ hổng thiết kế thú vị được gọi là sự cố Di chuyển / Sao chép.

Như đã giải thích trong bài viết MS KB này , các quyền cho thư mục hoặc tệp không tự động kế thừa từ cha nếu thư mục được di chuyển và nguồn và đích nằm trên cùng một ổ đĩa NTFS. Các quyền được kế thừa nếu thư mục được sao chép hoặc nếu nguồn và đích nằm trên các ổ đĩa khác nhau.

Đây là một ví dụ nhanh:

Bạn có hai thư mục được chia sẻ trên cùng một ổ NTFS được gọi là "Kỹ thuật viên" và "Người quản lý". Nhóm Kỹ thuật viên có quyền truy cập RW vào thư mục Kỹ thuật viên và nhóm Người quản lý có quyền truy cập RW vào thư mục "Người quản lý". Nếu ai đó có quyền truy cập vào cả hai và họ di chuyển thư mục con từ thư mục "Người quản lý" sang thư mục "Kỹ thuật viên", thư mục được di chuyển vẫn chỉ có thể truy cập đối với người dùng trong nhóm "Người quản lý". Nhóm "Kỹ thuật viên" không thể truy cập vào thư mục con mặc dù nó nằm trong thư mục "Kỹ thuật viên" và phải được kế thừa quyền từ đầu.

Như bạn có thể tưởng tượng, điều này gây ra các cuộc gọi hỗ trợ, vé và các chu trình lãng phí trong việc giải quyết các vấn đề của người dùng cuối này, chưa kể đến các tổ chức quyền mà bạn có thể kết thúc nếu người dùng thường di chuyển các thư mục giữa các thư mục / khu vực được bảo mật khác nhau trên cùng một thể tích.

Các câu hỏi là:

Cách tốt nhất để khắc phục lỗi thiết kế NTFS này là gì và bạn xử lý nó như thế nào trong môi trường của bạn?

Tôi biết bài viết KB được liên kết nói về một số khóa đăng ký để thay đổi hành vi mặc định của Windows Explorer nhưng chúng ở phía máy khách và yêu cầu người dùng có khả năng thay đổi quyền mà tôi nghĩ trong hầu hết các môi trường là không bắt đầu nếu bạn muốn giữ quyền kiểm soát các quyền máy chủ tệp của bạn (và sự tỉnh táo của bạn dưới dạng sysadmin).

— David Archer
nguồn

2

Tôi biết ví dụ về Người quản lý / Kỹ thuật viên chỉ để minh họa cho lỗ hổng, nhưng trong một số trường hợp đó là hành vi bạn muốn: nếu ai đó vô tình chuyển thư mục từ Người quản lý sang Kỹ thuật viên, bạn có thể không muốn Kỹ thuật viên có thể truy cập nó

— Phường - Phục hồi Monica

2

Đây thực sự không phải là một lỗ hổng, đây là cách hoạt động của quyền File. Nó đã được ghi nhận kể từ khi phát hành NTFS. Tôi không thể tin rằng một số người khuyên không nên sử dụng quyền truy cập tệp và chỉ sử dụng quyền chia sẻ để kiểm soát quyền truy cập. Điều này đi ngược lại những điều cơ bản về bảo mật cho máy chủ Microsoft File. Lý do di chuyển một thư mục / tệp trên cùng một ổ đĩa không kế thừa là vì thư mục / tệp không thực sự di chuyển trên đĩa, chỉ là con trỏ chúng ta thấy thay đổi.

— Michael Brown

12

Cách tiếp cận của tôi là không sử dụng quyền cấp tệp / thư mục cấp; sử dụng quyền cấp độ chia sẻ tệp và đặt toàn bộ ổ dữ liệu của hệ thống tệp máy chủ thành Mọi người kiểm soát hoàn toàn (sẽ trở thành moot).

Trong nhiều năm (10+), tôi đã thấy rằng các quyền NTFS phức tạp hơn và dẫn đến nhiều lỗi hơn. Nếu các quyền được đặt sai hoặc thừa kế bị hỏng, bạn sẽ lộ dữ liệu và rất khó để tìm và xem nó. Thêm vào đó, bạn tiếp xúc với vấn đề di chuyển / sao chép như bạn nói.

Những nơi bạn phải sử dụng thư mục / cấp độ tệp ACL; Tôi biết không có giải pháp nào khác ngoài việc kiểm tra sức khỏe một cách thường xuyên.

— James Risto
nguồn

10

Vâng, nó không thực sự là một lỗ hổng. Quy tắc này để xử lý các quyền khi di chuyển tệp đã được áp dụng kể từ ít nhất là phiên bản beta 2 của NT3.1 (mặc dù rõ ràng không phải là kế thừa vì điều đó chỉ được thêm vào với Windows 2000). Nó cũng nổi tiếng như bất kỳ tính năng nào của Windows. Tôi rất thông cảm với quan điểm của bạn, vì có thể có một vài người trong chúng ta chưa bị đốt cháy bởi điều này ở một giai đoạn. Nhưng đó là thứ mà sysadmin nhanh chóng học được.

JR

— John Rennie
nguồn

6

Tôi đã có một cuộc tranh luận với Raymond Chen trên blog của anh ấy về điều này. Microsoft "bán" NTFS như có quyền "thừa kế", sau đó hỗ trợ khi đường viền đặc biệt này trong bộ giáp được đưa lên. NTFS có quyền thừa kế tại thời điểm tạo tệp bằng cách đặt các ACE rõ ràng vào các tệp khi chúng được tạo. Tôi sẽ lập luận rằng, miễn là tài liệu và tài liệu tiếp thị nói về hệ thống thừa kế của họ như thể thời gian thực hoặc tài liệu hoặc mã bị lỗi. Họ nên chọn một và sửa nó.

— Evan Anderson

1

Vâng, đó là một sự đánh đổi. Nếu kế thừa là thời gian thực thì mỗi khi bạn mở một tệp ở dưới cùng của cây sâu, HĐH sẽ phải chạy lên cây để tìm ra các quyền hiệu quả là gì. Tất nhiên sự đánh đổi là nếu bạn thay đổi quyền ở đầu cây sâu, bạn phải chờ đợi! Không Active Directory sử dụng cùng một mô hình?

— John Rennie

Các đối tượng AD kế thừa chính xác quyền của cha mẹ mới khi được di chuyển giữa các vùng chứa và tôi sẽ cho rằng đây là hành vi "chính xác" dự kiến khi di chuyển tệp / thư mục trong NTFS.

— David Archer

3

@renniej: AD không sử dụng kế thừa thời gian thực. Hệ thống tập tin Netware đã làm điều đó từ lâu. NTFS cũng có thể đã làm điều đó, nếu Microsoft đã triển khai nó. Đó là "con đường chưa đi". Điều làm tôi khó chịu là tài liệu của Microsoft lại: NTFS và Explorer "chơi" giống như sự kế thừa là thời gian thực (tức là dối trá). Nói với chúng tôi như nó là, hoặc sửa chữa hành vi để đi đôi với tài liệu!

— Evan Anderson

@renniej Như Evan Anderson đã nói, Netware đã làm điều này vào năm 1990 khi họ còn là vua. Vấn đề có thể khắc phục bằng cách tạo một chỉ mục hệ thống tệp khác theo dõi 'danh sách hiển thị'. Microsoft đã chọn không làm điều đó, nhưng có thể hình dung ra một cách rõ ràng để phát hành Windows Server trong tương lai.

— sysadmin1138

6

Chúng tôi đã sử dụng NTFS kể từ NT 3.51 và mặc dù chúng tôi đã thấy "vấn đề" này (cũng như hầu hết mọi người), nó đã không gây ra cho chúng tôi nhiều rắc rối:

Chúng tôi luôn bảo mọi người sao chép tệp nếu họ cần di chuyển chúng từ thư mục dùng chung này sang thư mục khác. "Giữ phím CTRL khi kéo và đảm bảo rằng dấu + nhỏ đang hiển thị" là cụm từ phổ biến.
Các thư mục được chia sẻ của chúng tôi có cấu trúc khá đơn giản và các thư mục được chia sẻ mà chúng tôi tạo ra không giao thoa giữa các nhóm quá thường xuyên, vì vậy mọi người có nhiều khả năng muốn sao chép các tệp ở vị trí đầu tiên.
Chúng tôi thấy vấn đề chủ yếu nằm ở không gian "chung" của chúng tôi - nơi mọi người đều có thể đọc / ghi, nhưng những thư mục đó chủ yếu tồn tại trong thời gian ngắn nên vấn đề sẽ biến mất khi chúng bị thanh trừng.

— Phường - Phục hồi Monica
nguồn

4

Cách giải quyết tôi có thể nghĩ ra:

tìm cách tạo các thư mục có quyền khác nhau trên các ổ NTFS khác nhau
Thực hiện một tác vụ theo lịch trình (một lần một giờ hoặc một lần mỗi ngày tùy thuộc vào tần suất của các yêu cầu hỗ trợ) chạy qua các thư mục và đặt lại tất cả các quyền giống như các quyền từ cấp cao nhất. Điều này ít hơn lý tưởng, vì vậy nếu các thư mục có nhiều tệp trong đó, nhưng là một vấn đề sẽ khắc phục sự cố nếu không có giải pháp tốt như sửa lỗi đăng ký phía máy chủ. Lệnh bạn sẽ muốn xem được gọi là 'cacls' mà sau đó bạn có thể thêm vào một tệp bó.

Tuyên bố miễn trừ trách nhiệm - Tôi đến từ một nền tảng unix (và đã triển khai cái cuối cùng để sửa các lỗi quyền khác nhau - nó cảm thấy khó chịu, nhưng thực hiện công việc), vì vậy có thể có cách khắc phục tốt hơn nhiều.

— dấu
nguồn

+1 - Câu trả lời đầu tiên mà Mark đưa ra là sự lựa chọn tốt nhất. Đó là một nỗi đau, nhưng đó là cách tốt nhất của bạn để giải quyết quyết định thiết kế ngu ngốc này trong NTFS 5.

— Evan Anderson

Để mở rộng: Đây là nơi mà những người bạn sử dụng SharePoint của tôi sẽ nói "sử dụng SharePoint"! Tương tự, bạn bè kiểm soát phiên bản của tôi và bạn bè kiểm soát tài liệu hệ thống của tôi sẽ trỏ đến Subversion, Documentum, v.v. và nói "sử dụng điều đó". Sự lựa chọn thiết kế trong NTFS này là một mụn cóc lớn, và nó gần như khiến bạn tự hỏi liệu Microsoft có thực sự sử dụng phần mềm của riêng họ khi bạn phải chiến đấu với nó trong mạng riêng của mình không. (Nó hét lên với tôi rằng Microsoft không sử dụng phần mềm của họ trong cùng một cách mà chúng ta làm w / người dùng của chúng tôi, thực sự Phải là tốt đẹp để có một công ty điền w / "công nhân tri thức"..)

— Evan Anderson

1

Tôi đồng ý rằng lý tưởng là chúng ta có thể tách tất cả các thư mục được chia sẻ thành khối lượng riêng của chúng, trong thực tế, điều này không khả thi đối với một môi trường rộng lớn (hàng ngàn thư mục được chia sẻ). Ngoài ra, không có một số điểm giao tiếp thú vị hoặc voodoo symlink, điều này có nghĩa là mất khả năng có các thư mục con lồng nhau với các quyền khác nhau trên chúng.

— David Archer

1

@David: Di chuyển dữ liệu trên các cổ phiếu sẽ dẫn đến một bản sao và xóa. Di chuyển dữ liệu trong một chia sẻ sẽ dẫn đến một di chuyển. Nếu bạn đặt mỗi thư mục dùng chung gốc của hệ thống phân cấp quyền mà không có thư mục con nào có quyền hạn chế hơn, bạn sẽ giảm bớt vấn đề. Vẫn xấu xí, mặc dù. (Tôi có máy chủ W2K3 với hơn 2200 thư mục được chia sẻ riêng lẻ trên đó và tôi không thấy vấn đề về hiệu suất ...)

— Evan Anderson

3

Khi chuyển sang làm quản trị viên, tôi sử dụng xcopy / s / e / c / h / r / k / y - mọi thứ ngoài quyền sở hữu tệp và ACL, có nghĩa là quyền thừa kế ACL tự động khởi động. Không bao giờ thực sự phải đối phó với tình huống người dùng di chuyển công cụ mặc dù.

— Maximus Minimus
nguồn

2

Người dùng của bạn còn sống không?

— Evan Anderson

4

Đôi khi tôi tự hỏi ...

— Maximus Minimus

@Even: Có lẽ không ai trong số họ thuộc hai nhóm!

— SamB

+1 cho những người dẫn đầu đến công cụ giải quyết vấn đề này khi duy trì các tệp (cùng với nhiều người khác); tuy nhiên, XCOPY đã bị khấu hao: ROBOCOPY.EXE là người kế thừa rất có khả năng của nó.

— jnaab

2

Xin lỗi vì nitpicking, nhưng không xcopy _copy_ các tệp (thay vì _moving_ các tệp?) - có vẻ như tác giả không có vấn đề gì với việc sao chép, anh ta chỉ gặp vấn đề với _moving_. Tôi có thể sai về bc thiếu kinh nghiệm này, vì vậy hãy sửa cho tôi nếu tôi sai (tức là bạn có sử dụng lệnh 'del' sau khi sử dụng 'xcopy', vì vậy các tệp thực sự bị 'sao chép và xóa'! = di chuyển?)

— colemik

3

Tôi sử dụng chính sách nhóm / chính sách bảo mật / hệ thống tệp để theo dõi các quyền phức tạp. (KHÔNG BAO GIỜ sử dụng "quyền thay thế" trong chính sách).

Lên lịch CACLS để thiết lập lại tất cả các quyền trong đêm sau đó là gpupdate / lực lượng để áp dụng lại quyền từ chính sách. Hoạt động như một lá bùa.

— Alexandru Nica
nguồn

Có lẽ điều này chỉ dành cho máy chủ Windows? Vì Chính sách nhóm phải được áp dụng cho các đối tượng miền, điều này không thể được áp dụng cho các chia sẻ lưu trữ không phải Windows mà tôi tưởng tượng?

— Giàu M

2

Vì Windows 7 (hoặc có thể là Windows Vista), các quyền đối với thư mục hoặc tệp DO được thừa hưởng từ cha mẹ nếu thư mục được di chuyển và nguồn và đích nằm trên cùng một ổ đĩa NTFS - nếu một tệp hoặc thư mục được sao chép qua Explorer. Trong một hệ điều hành trước đó, bạn có thể sử dụng Trình quản lý xa - nó cho phép kích hoạt quyền thừa kế từ đích (cùng với hàng tấn các tính năng khác). Mặc dù Far có vẻ không thân thiện với người dùng nói chung.

— GCRaistlin
nguồn

0

Một cách giải quyết rất đơn giản là chỉ cần nén các tệp và giải nén nó vào thư mục đích.

— Bob
nguồn

Tôi vừa mới thử cái này và không may nó không hoạt động. Các quyền trên kho lưu trữ zip là khác nhau trước khi tôi thậm chí đã làm bất cứ điều gì với nó. Các quyền được kế thừa vẫn còn nhưng các quyền rõ ràng không được tạo.

— Giàu M