Tại sao là chmod -R 777 /R bị phá hủy?

Đây là một Câu hỏi Canonical về Quyền của Tệp và Tại sao 777 là "phá hoại".

Tôi không hỏi làm thế nào để khắc phục vấn đề này, vì có rất nhiều tài liệu tham khảo đã có trên Server Fault (cài đặt lại HĐH). Tại sao nó làm bất cứ điều gì phá hoại cả?

Nếu bạn đã từng chạy lệnh này, bạn sẽ phá hủy hệ điều hành của mình ngay lập tức. Tôi không rõ tại sao loại bỏ các hạn chế có bất kỳ tác động nào đến các quy trình hiện có. Ví dụ: nếu tôi không đọc được quyền truy cập vào một cái gì đó và sau khi gõ nhầm vào thiết bị đầu cuối đột nhiên thì bây giờ tôi có quyền truy cập tốt ... tại sao điều đó khiến Linux bị hỏng?

Trước hết, một thuật ngữ nhỏ nitpick: chmodkhông xóa quyền. Nó THAY ĐỔI họ.

Bây giờ là vấn đề cốt lõi - Chế độ 777có nghĩa là "Bất kỳ ai cũng có thể đọc, viết hoặc thực hiện tệp này" - Bạn đã cấp phép cho bất kỳ ai làm (một cách hiệu quả) bất cứ điều gì họ muốn.

Bây giờ, tại sao điều này là xấu?

1. Bạn chỉ để mọi người đọc / sửa đổi mọi tập tin trên hệ thống của bạn.
   • Hôn tạm biệt mật khẩu (bất kỳ ai cũng có thể đọc tệp bóng và bẻ khóa mật khẩu của bạn, nhưng tại sao phải bận tâm? Chỉ cần THAY ĐỔI mật khẩu! Dễ dàng hơn nhiều!).
   • Hôn an ninh cho tạm biệt nhị phân của bạn (ai đó chỉ có thể viết một loginchương trình mới cho phép họ mọi lúc).
   • Hôn tạm biệt các tệp của bạn: Một người dùng định hướng sai rm -r /và tất cả đã kết thúc. HĐH được yêu cầu để họ làm bất cứ điều gì họ muốn!
2. Bạn đã bực mình với mọi chương trình kiểm tra quyền trên các tập tin trước khi bắt đầu.
   sudo, sendmailvà một loạt những người khác chỉ đơn giản là sẽ không bắt đầu nữa. Họ sẽ kiểm tra các quyền của tệp chính, xem chúng không phải là những gì chúng được cho là và gửi lại thông báo lỗi.
   Tương tự như vậy sshsẽ phá vỡ khủng khiếp (các tệp chính phải có quyền cụ thể, nếu không chúng "không an toàn" và theo mặc định SSH sẽ từ chối sử dụng chúng.)
3. Bạn đã xóa sạch các bit setuid / setgid trên các chương trình có chúng.
   Chế độ 777là thực sự . Trong số những thứ trong chữ số hàng đầu đó là và bit. Hầu hết các chương trình setuid / setgid đều có bit đó vì chúng phải chạy với một số đặc quyền nhất định. Bây giờ họ đang tan vỡ.0777setuidsetgid
   
4. Bạn đã bị hỏng /tmpvà/var/tmp một điều khác trong chữ số bát phân hàng đầu không có đó là sticky bit- Điều đó bảo vệ các tệp trong /tmp(và /var/tmp) khỏi bị xóa bởi những người không sở hữu chúng.
   Có (rất tiếc) có rất nhiều đoạn script bị xử lý xấu ngoài kia "dọn dẹp" bằng cách thực hiện rm -r /tmp/*và không có bit dính trên /tmp bạn có thể hôn tạm biệt tất cả các tệp trong thư mục đó.
   Việc các tệp cào biến mất thực sự có thể làm đảo lộn một số chương trình được viết xấu ...
5. Bạn đã gây ra sự tàn phá trong /dev /proccác hệ thống tệp tương tự
   Đây là vấn đề xảy ra với các hệ thống Unix cũ hơn /devlà hệ thống tệp thực và nội dung chứa trong đó là các tệp đặc biệt được tạo mknod, vì sự thay đổi quyền sẽ được lưu giữ trong quá trình khởi động lại, nhưng trên bất kỳ hệ thống nào việc thay đổi quyền thiết bị của bạn có thể gây ra sự cố đáng kể, từ các rủi ro bảo mật rõ ràng (mọi người đều có thể đọc mọi TTY) đến các nguyên nhân tiềm ẩn ít rõ ràng hơn của sự hoảng loạn hạt nhân.
   Credit to @Tonny for pointing out this possibility
6. Ổ cắm và đường ống có thể bị vỡ, hoặc có các vấn đề khác Ổ cắm và đường ống có thể bị vỡ hoàn toàn hoặc tiếp xúc với thuốc tiêm độc hại do hậu quả của việc viết ra trên thế giới.
   Credit to @Tonny for pointing out this possibility
7. Bạn đã tạo mọi tệp trên hệ thống của mình có thể thực thi
   Rất nhiều người có .trong PATHbiến môi trường của họ (bạn không nên!) - Điều này có thể gây ra một bất ngờ khó chịu vì bây giờ bất kỳ ai cũng có thể thả một tệp có tên thuận tiện như một lệnh (nói makehoặc ls, và có cơ hội giúp bạn chạy mã độc của họ.
   Credit to @RichHomolka for pointing out this possibility
8. Trên một số hệ thống chmodsẽ thiết lập lại Danh sách điều khiển truy cập (ACL)
   Điều này có nghĩa là bạn có thể sẽ phải tạo lại tất cả các ACL của mình ngoài việc sửa các quyền ở mọi nơi (và là một ví dụ thực tế của lệnh bị phá hủy).
   Credit to @JamesYoungman for pointing out this possibility

Các bộ phận của hệ thống đang chạy sẽ tiếp tục chạy chứ? Có lẽ, trong một thời gian ít nhất.
Nhưng lần tới khi bạn cần khởi chạy một chương trình, hoặc khởi động lại một dịch vụ, hoặc trời cấm REBOOT hộp bạn đang ở trong một thế giới bị tổn thương vì # 2 và # 3 ở trên sẽ nuôi dưỡng những cái đầu xấu xí của họ.

Một điều quan trọng là có nhiều công cụ như ssh / sudo kiểm tra các quyền của hệ thống tập tin cho các tệp cấu hình chính. Nếu các quyền sai, các công cụ này được thiết kế để thất bại, vì điều này sẽ chỉ ra một vấn đề bảo mật nghiêm trọng. Trên hệ thống kiểm tra Debian của tôi và có lẽ trên các hệ thống khác, khả năng đăng nhập thất bại, có thể là do nhị phân đăng nhập hoặc thứ gì đó trong PAM có kiểm tra quyền.

Vì vậy, thực sự không phải là hệ thống bị phá hủy - nhiều công cụ được thiết kế để ngay lập tức bị lỗi khi cấp phép sai.

Nếu bạn khởi động lại một hệ thống sau khi thực hiện, chmod 777 -R /nó sẽ khởi động và bạn có thể bắt đầu các quy trình không có kiểm tra quyền rõ ràng. Vì vậy, hệ thống không thực sự chết, chỉ là thiết kế phụ không sử dụng được .