Làm cách nào để xóa thư mục không trống mà người dùng không sở hữu trong Linux?


10

Nếu một thư mục "foo" được sở hữu bởi người dùng A và chứa một thư mục "bar", thuộc sở hữu của root, người dùng A có thể chỉ cần xóa nó với rmdir, đó là logic, bởi vì "foo" có thể ghi được bởi người dùng A.

Nhưng nếu thư mục "bar" chứa một tệp thuộc sở hữu gốc khác, thư mục không thể bị xóa, vì các tệp trong đó phải được xóa trước, vì vậy nó trở nên trống rỗng. Nhưng bản thân "thanh" không thể ghi được, vì vậy không thể xóa các tệp trong đó.

Có cách nào xung quanh nó? Hoặc, thuyết phục tôi bằng cách khác tại sao nó cần thiết.

Câu trả lời:


7

Giải thích 1: một thư mục là một không gian con của hệ thống tập tin. Nó có thể được chia nhỏ thành các không gian con bằng cách tạo các thư mục con trong đó. Chủ sở hữu của thư mục foonên có thể kiểm soát tất cả mọi thứ bên trong không gian con: foo/bar, foo/bar/quxvv

Giải thích 2: một thư mục là một không gian con của hệ thống tập tin. Mỗi thư mục được đính kèm với một số thư mục khác, được gọi là cha mẹ của nó. Chủ sở hữu của thư mục foocó quyền kiểm soát mọi thứ bên trong không gian con; tuy nhiên, đối với thư mục con foo/bar, chủ sở hữu foocó quyền kiểm soát xem barcó thể được đính kèm hay fookhông nhưng không liên quan đến những gì bên trong bar: chỉ chủ sở hữu mới barcó quyền kiểm soát đó.

Bằng chứng có lợi cho giải thích 2: như bạn đã lưu ý, cách thức hoạt động của quyền. Ngoài ra, thực tế là một số hệ thống tập tin Unix cho phép một thư mục được gắn vào nhiều phụ huynh: điều này được gọi là có nhiều liên kết cứng. (Có nhiều liên kết cứng là phổ biến đối với các tệp thông thường, nhưng nó thường không được khuyến khích hoặc cấm đối với các thư mục chủ yếu vì rủi ro tạo vòng lặp, trong đó một thư mục là ông bà của chính nó N bị xóa - vì vậy bạn không thể truy cập nó từ thư mục gốc thư mục, đó là một kỳ vọng rất phổ biến. Ngoài ra còn có vấn đề phải làm gì nếu một thư mục có 0 liên kết cứng nhưng không trống: vì thư mục không được lưu trữ, bạn muốn xóa nó, nhưng bạn sẽ làm gì với nó nội dung?)

Bằng chứng ủng hộ cho việc giải thích 1: trong thực tế, các thư mục có một cha mẹ duy nhất và do đó tạo thành một cấu trúc cây. Và bạn không thể truy cập foo/bar/quxtrừ khi bạn đã thực thi quyền foocũng như bar(tốt, ngoại trừ việc có một số cách tối nghĩa để được cấp quyền truy cập barmà không được cấp quyền truy cập foo). Vì vậy, các cấp trên làm vấn đề.

Trên một lưu ý thực tế hơn, trong tình huống của bạn, người dùng A có thể làm

rác mkdir
mv foo / thanh rác /
rmdir foo

1
Đây là một câu trả lời tuyệt vời (rec'ed), nhưng sự không nhất quán rõ ràng vẫn làm tôi bực bội. Và trong khi ví dụ thực tế về việc chuyển thanh sang rác không hoạt động, chúng ta sẽ để lại một thư mục gọi là rác không thể xóa được. Tôi cũng gặp vấn đề tương tự, ngoại trừ người dùng A và người dùng B, trong đó B mắc kẹt một thứ gì đó trong thư mục do A sở hữu, mà A muốn xóa.
Paul Hooper

Đây là một lời giải thích tốt, nhưng ví dụ ở cuối sử dụng mvđể phá vỡ vấn đề không phù hợp với tôi trên Raspbian (chưa thử trên bất kỳ hệ thống nào khác). Hơn nữa, khi nghiên cứu vấn đề này, tôi chưa thấy việc sử dụng mvnhư một giải pháp được đề cập ở bất kỳ nơi nào khác. Thật vậy, dựa trên sự hiểu biết của tôi về cách các quyền hoạt động, có nghĩa là sự mvthất bại khi tôi đã thử nó. Tui bỏ lỡ điều gì vậy? Hoặc có chức năng này có lẽ đã thay đổi? @Gilles @PaulHooper
fvgs

@fvss Không có gì thay đổi, nhưng tình huống của bạn có thể có các quyền khác với điều này. Tôi khuyên bạn nên hỏi một câu hỏi mới (trên Unix & Linux thay vì Server Fault vì câu hỏi này có thể bị coi là lạc đề nếu bây giờ nó được hỏi trên SF) và cung cấp tất cả các chi tiết về tình huống của bạn.
Gilles 'SO- ngừng trở nên xấu xa'

@Gilles Bạn có thể vui lòng chỉ cho tôi một số tài liệu, tài liệu tham khảo hoặc đề cập đến hành vi bạn mô tả cho mv? Tôi có thể sử dụng mvđể đổi tên thư mục thanh. Có nghĩa là mvthành công miễn là tôi không cố gắng di chuyển thanh bên ngoài thư mục hiện tại hoặc vào bất kỳ thư mục khác. Nhưng ví dụ bạn đưa ra (di chuyển thanh thư mục) không hoạt động đối với tôi (quyền bị từ chối). Có phải ví dụ bạn đưa ra giả định các điều kiện cụ thể khác với các điều kiện được chỉ định trong câu hỏi không?
fvss

@fvss Ví dụ của tôi không di chuyển barlên một thư mục, nó di chuyển nó đến một thư mục mà bạn sở hữu. garbagecó thể là bất cứ nơi nào trên cùng một hệ thống tập tin, không nhất thiết phải là anh chị em của foo.
Gilles 'SO- ngừng trở nên xấu xa'

0

Cách duy nhất để giải quyết vấn đề này là sử dụng setgid hoặc setuid trên thư mục mẹ hoặc sử dụng ACL.

Đặt thư mục setgid với

chmod g+s foo

Đặt ACL mặc định cho nó với

setfacl -d -R -m g:group:rwx foo

Cái này đặt nó làm ACL mặc định trên đường dẫn này. Bạn phải gắn kết hệ thống tập tin có chứa đường dẫn này với tùy chọn acl!

Bây giờ hãy nói cho tôi tại sao bạn nghĩ rằng bạn muốn điều này.


Vâng, vấn đề là một sự nhất quán. Không có gì ngăn tôi xóa một tập tin hoặc một thư mục trống thuộc sở hữu của một người dùng khác trong một thư mục mà tôi sở hữu, nhưng nếu nó không trống, tôi bị khóa khỏi việc xóa thư mục của riêng tôi.
Alex B

Nếu đó là trường hợp, tôi sẽ sử dụng một trong các tùy chọn tôi cung cấp. Họ sẽ làm việc tốt cho bạn.
wzzrd

Tôi thường sử dụng nhiều tài khoản trên máy tính để bàn của mình (một trong số đó là tài khoản "không chính gốc"). Tôi cũng có thể có được tình huống như vậy khi make installbắt đầu từ root bắt đầu xây dựng một cái gì đó.
Vi.

setgid trên thư mục cha không giúp được. Sau khi thực hiện root, cd ~user && mkdir qqq && touch qqq/qqqtôi không thể thoát khỏi qqq từ người dùng chmod g+s .rm -Rf qqq.
Vi.

Ừm. Đó có lẽ là một vấn đề quan trọng. Nếu thư mục của bạn là 775, thì setgid và umask của bạn là 0002, sau đó các tệp có thể ghi được cho nhóm và do đó có thể tháo rời cho bạn. Nhưng, sự thật, nó không hoạt động với umask 0022 (phần lớn là mặc định). Nên đã nói rằng. Bạn đã thử nghiệm tùy chọn acl?
wzzrd
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.