Tại sao quyền truy cập tệp được giữ lại khi di chuyển tệp trong cùng một ổ đĩa?


9

Thỉnh thoảng, chúng tôi gặp vấn đề là một tệp có quyền khác với thư mục chứa nó.

Bây giờ tôi phát hiện ra rằng có một bài viết KB giải thích lý do đằng sau điều này:

Theo mặc định, một đối tượng kế thừa các quyền từ đối tượng cha của nó, tại thời điểm tạo hoặc khi nó được sao chép hoặc di chuyển đến thư mục mẹ của nó. Ngoại lệ duy nhất cho quy tắc này xảy ra khi bạn di chuyển một đối tượng sang một thư mục khác trên cùng một ổ đĩa. Trong trường hợp này, các quyền ban đầu được giữ lại.

Vì vậy, người dùng đã di chuyển tệp từ thư mục này sang thư mục khác và các quyền từ thư mục gốc được giữ lại.

Câu hỏi của tôi bây giờ là: tại sao ngoại lệ này tồn tại? Lý do đằng sau này là gì?

Câu trả lời:


9

Tôi đã giải thích điều này trong một bài đăng trên blog http://think-like-a-computer.com/2011/07/24/moving-files-on-the-same-ntfs-volume-does-inherit-permissions/ nhưng nó cũng được giải thích dưới đây.

Khi một tệp được sao chép, nó phải tạo một tệp hoàn toàn mới và gán cho nó một bộ quyền mới, để nó có được các quyền từ thư mục mẹ như bạn biết.

Khi một tệp được chuyển sang ổ đĩa khác, điều thực sự xảy ra là nó được sao chép sang ổ đĩa mới và tập tin cũ sẽ bị xóa. Vì vậy, quá trình tương tự được lặp lại như trên vì nó là một tệp mới một lần nữa và cần thiết lập quyền.

Khi tệp được di chuyển trong cùng một ổ đĩa, không có gì thực sự xảy ra (ở cấp độ đĩa). Nó chỉ thay đổi vị trí đường dẫn logic của tệp. Dữ liệu thực tế và tệp vật lý trên đĩa chưa được chạm hoặc thay đổi. Bạn có bao giờ nhận thấy khi bạn di chuyển tệp 5 GB sang thư mục khác trên cùng ổ đĩa, nó được thực hiện gần như ngay lập tức? Đây là lý do tại sao, vì nó thực sự không di chuyển nhưng con trỏ đến nơi tệp tồn tại một cách hợp lý đã thay đổi. Vì nó không được sửa đổi theo bất kỳ cách nào, các quyền cũng không thay đổi.

Đây là lý do cho hành vi này.

Chỉnh sửa: Một cái gì đó tôi quên đề cập đến ... Bài viết MS không hoàn toàn chính xác. Báo giá của MS:

Theo mặc định, một đối tượng kế thừa các quyền từ đối tượng mẹ của nó, tại thời điểm tạo hoặc khi nó được sao chép hoặc di chuyển đến thư mục mẹ của nó. Ngoại lệ duy nhất cho quy tắc này xảy ra khi bạn di chuyển một đối tượng sang một thư mục khác trên cùng một ổ đĩa. Trong trường hợp này, các quyền ban đầu được giữ lại.

Báo giá trên chỉ áp dụng cho các đối tượng đã được cấp quyền EX được xác định TUYỆT VỜI (tắt tính kế thừa). Như đã đề cập trong các bình luận của tôi, tất cả là về việc giữ các mục ACL hiệu quả nhất có thể. Hãy xem xét ví dụ sau:

Để giữ cho lời giải thích đơn giản, giả sử bạn có một thư mục được đặt để chỉ cho phép người dùng sửa đổi quyền. Bên dưới này, có hàng ngàn tệp và không ai trong số chúng có quyền rõ ràng được đặt. Sẽ không hiệu quả lắm khi tạo ACL cho mỗi tệp vì chúng chính xác là cùng một phép cho phép nó đặt MỘT mục nhập ACL cho thư mục. Bit tiếp theo này là rất quan trọng để hiểu; bản thân các tệp KHÔNG CÓ PERL ACMS. Vì vậy, khi bạn di chuyển bất kỳ tệp nào trong số này vào một thư mục mới trong cùng một ổ đĩa, MS sẽ yêu cầu các perm di chuyển với nó (như trích dẫn ở trên). Hãy tự hỏi mình .... làm thế nào? Không có perm trên tập tin ở nơi đầu tiên để di chuyển qua. Điều này thực sự không chính xác và tôi chỉ kiểm tra nó ngay bây giờ để xác nhận nó. Giả sử thư mục đích bạn đang di chuyển tệp có các perm cho phép chỉ cho phép mọi người sửa đổi quyền. Vì tệp không có ACL trực tiếp nên nó thừa hưởng ACL của thư mục mẹ. Điều này có nghĩa là perms đã thay đổi từ người dùng sửa đổi (thư mục cũ) sang mọi người sửa đổi (thư mục mới).

Chú ý sự khác biệt?? Lần này, việc di chuyển một tập tin sang một thư mục khác trong cùng một tập thực sự đã thay đổi các perm, điều mà MS nói là không làm được. Có phải tôi đã tìm thấy một lỗi trong tài liệu MS từ năm 2000 lol ??

Bây giờ hãy nhìn vào kịch bản tương tự khi sử dụng quyền rõ ràng. Nếu bạn đặt quyền rõ ràng trên một tệp trong thư mục này (tắt tính kế thừa), ví dụ, từ chối người dùng đọc quyền truy cập, thì bây giờ nó sẽ tạo một mục ACL MỚI dành riêng cho tệp này. Bây giờ khi bạn di chuyển tệp đến một vị trí mới, nó có mục ACL liên quan trực tiếp đến nó. Trong trường hợp này, di chuyển một tệp đến một vị trí mới trong cùng một khối lượng RETAINS quyền của nó (như MS tuyên bố)!


+1 Cả hai đều là câu trả lời tốt, nhưng câu trả lời của bạn có ý nghĩa hơn. Tôi thích nhận xét của bạn về cách tệp 5GB di chuyển ngay lập tức. Hình ảnh tốt.
KCotreau

Tôi có xu hướng nghĩ rằng "không có bản sao đang xảy ra" là lý do chính khiến ACL không được chạm vào.
VVS

1
Không có lý do kỹ thuật nào để thay đổi bảng hệ thống tập tin không ảnh hưởng đến mục nhập ACL tương ứng. Tôi nghĩ rằng lời giải thích này là chính xác. Nhưng tôi cũng nghĩ rằng nó mô tả hiệu quả, không phải là nguyên nhân thực sự. Nguyên nhân là do mô hình bảo mật của ACL, dựa trên khối lượng. Di chuyển / sao chép các hoạt động giữa các khối lượng khác nhau được hiểu là sự chuyển giao các đặc quyền và thay đổi trong cùng một khối lượng như là bất khả tri đặc quyền. Theo mặc định, tự nhiên.
Một chú lùn

Thêm vào đó là hành vi dự kiến. Người dùng sẽ không mong đợi rằng việc di chuyển / sao chép tệp từ tài liệu sang hình ảnh sẽ đột nhiên bị từ chối Đọc quyền truy cập. Hoặc việc sao chép một tập tin sẽ làm mất tập tin mã hóa đột ngột. Tôi có thể nghĩ về 1000 kịch bản ác mộng khác. . .
Surfasb

Và theo logic, các quyền đối với một tệp được thiết lập khi tạo. Lưu ý khi bạn thay đổi quyền trên một thư mục mà bạn phải truyền quyền cho tất cả các đối tượng con. Đó là lý do tại sao Windows đôi khi đưa ra một hộp thoại vì nó thay đổi tất cả các đối tượng con nếu có rất nhiều.
Surfasb

6

Khi bạn di chuyển các tệp trong cùng một ổ đĩa, bạn thường sắp xếp lại hệ thống tệp của mình . Việc thay đổi quyền truy cập tệp ở cấp thư mục có thể khóa bạn khỏi tệp đó ngay khi thao tác di chuyển kết thúc. Điều này là không mong muốn nếu, chẳng hạn, bạn chỉ vô tình di chuyển một tệp vào hệ thống hoặc một thư mục có quyền sở hữu đặc biệt hoặc được bảo vệ theo cách khác. Sẽ không có cách nào để sửa lỗi ngoài việc sở hữu tệp (nếu bạn có đặc quyền) hoặc đăng nhập bằng tài khoản đặc quyền. Xem xét hoạt động bình thường hàng ngày của máy tính, bạn có thể thấy bạn không có quyền kiểm soát hệ thống tập tin của mình.

Hành vi này là phổ biến trong hầu hết (nếu không phải tất cả) các hệ điều hành sử dụng ACL. Nó đảm bảo các hoạt động hệ thống tập tin bình thường trong một khối lượng bởi người dùng và các ứng dụng như nhau.

Ngược lại, khi di chuyển các tệp giữa các tập, bạn thường cho một tập tin để kiểm soát bởi một cái gì đó hoặc người khác. Thật có ý nghĩa, khi bạn nhận ra rõ ràng, khi đó tệp sẽ kết hợp các quyền của thư mục đích, nó sẽ cung cấp cho mục tiêu các quyền cần thiết để sắp xếp lại hệ thống tệp của chính nó khi chúng thấy phù hợp.

Đương nhiên điều này không phải luôn luôn mong muốn. Vì lý do di chuyển và sao chép hoạt động có thể được xác định với các quy tắc thừa kế cho phép đặc biệt. Từ cùng một bài viết:

  • Để duy trì quyền khi tệp và thư mục được sao chép hoặc di chuyển, hãy sử dụng tiện ích Xcopy.exe với công tắc / O hoặc / X. Các quyền ban đầu của đối tượng sẽ được thêm vào các quyền kế thừa ở vị trí mới.

  • Để thêm các quyền ban đầu của một đối tượng vào các quyền kế thừa khi bạn sao chép hoặc di chuyển một đối tượng, hãy sử dụng tiện ích Xcopy.exe với các khóa chuyển đổi của NottO và.


"Điều này là không mong muốn nếu, chẳng hạn, bạn chỉ vô tình di chuyển tệp vào hệ thống hoặc thư mục có quyền sở hữu đặc biệt hoặc được bảo vệ theo cách khác." - Vì vậy, bạn di chuyển một tệp, ví dụ như vào một thư mục có quyền ghi và vẫn có thể di chuyển tệp trở lại .. tại sao điều này không mong muốn về các khối lượng khác nhau?
VVS

1
@VVS vì ACL là mô hình bảo mật dựa trên hệ thống tệp. Mỗi ổ chứa hệ thống tập tin riêng của nó và do đó (các) bảng ACL của riêng nó. Từ góc độ bảo mật ACL, một khối lượng khác tương đương với một "người dùng" khác. Bằng cách di chuyển tệp đến một ổ đĩa khác, bạn sẽ chuyển điều khiển cho "người dùng" đó. Nhưng bạn vẫn được cung cấp tùy chọn không nếu thực sự bạn rất mong muốn. Đó chỉ là hành vi mặc định giải quyết các mối quan tâm bảo mật ACL.
Một chú lùn

1

OK Đây là mức thấp thực sự. Đầu tiên - chúng ta đang nói về một PC hoặc một máy chủ? Tôi giả sử chúng ta đang nói về một Máy chủ. Vì vậy, với tư cách là Quản trị viên Wintel của Công ty A, bạn tạo một hệ thống tệp trên ổ đĩa mạng trên máy chủ mới của mình. Bạn dựa trên các phòng ban, tức là mỗi phòng ban có một thư mục và mỗi thư mục có ACL riêng vì vấn đề bảo mật, có lẽ là chuẩn mực - có? Do đó, nếu bạn định chuyển một tập tin sang thư mục của bộ phận khác, tại sao bạn lại KHÔNG muốn nó kế thừa các perm của thư mục mới? Ý tôi là ... tại sao bạn có một hệ thống tập tin dựa trên quyền nếu bạn sẽ không sử dụng nó? Tôi có thể cung cấp cho bạn một ví dụ thực tế trong đó điều quan trọng đối với các tệp / thư mục đã di chuyển là luôn kế thừa ACL của thư mục mẹ của chúng, chỉ cần hỏi tôi.

Di chuyển các tệp trong một ổ đĩa hoặc di chuyển chúng từ vol X sang vol Y ... sự khác biệt cơ bản là gì? Bạn đang di chuyển vị trí của một số tệp - qua các khối lượng khác nhau hoặc không tạo ra sự khác biệt trong môi trường công ty theo như tôi có thể thấy. Lý do thực sự tại sao một cái bao gồm thừa kế theo mặc định và cái kia không được Mucker đề cập - đó là "hiệu quả". Kéo và thả tệp trong một ổ đĩa chỉ thay đổi mục Chỉ mục - các tệp không được di chuyển và thông tin ACL của chúng được để lại một mình. Làm cho một hoạt động đơn giản. Tuy nhiên, khi các tệp được di chuyển qua các ổ đĩa, các tệp và ACL của chúng phải được xác định lại, do đó, việc thực hiện đúng và bao gồm cả kế thừa có ý nghĩa tốt vì nó không phải chịu một chi phí có thể tránh được.

Tôi không thể hiểu tại sao Microsoft không giải quyết vấn đề này. Sẽ rất khó để bao gồm một hộp thoại như là một phần của trình kéo thả của Explorer? Một cái gì đó như "Bạn đã di chuyển các tệp đến một vị trí có quyền truy cập khác nhau, bạn có muốn kế thừa các quyền của thư mục gốc mới không? Y hoặc N?"

Trân trọng, Stonegiant

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.