Có một lý do tại sao quyền của chủ sở hữu tồn tại? Không đủ quyền nhóm?

Tôi nghĩ rằng tôi hiểu cách thức hoạt động của quyền trong Linux. Tuy nhiên, tôi không thực sự hiểu tại sao chúng được chia thành ba cấp độ chứ không chia thành hai cấp độ.

Tôi muốn các vấn đề sau đây được trả lời:

• Đây là thiết kế có chủ ý hay một bản vá? Đó là - các quyền của chủ sở hữu / nhóm được thiết kế và tạo cùng với một số lý do hay họ đã lần lượt từng người một để trả lời một nhu cầu?
• Có một kịch bản mà người dùng / nhóm / lược đồ khác hữu ích nhưng một nhóm / lược đồ khác sẽ không đủ?

Câu trả lời đầu tiên nên trích dẫn sách giáo khoa hoặc bảng thảo luận chính thức.

Các trường hợp sử dụng tôi đã xem xét là:

• các tệp riêng tư - rất dễ dàng có được bằng cách tạo một nhóm cho mỗi người dùng, một việc thường được thực hiện như trong nhiều hệ thống.
• chỉ cho phép chủ sở hữu (ví dụ: dịch vụ hệ thống) ghi vào tệp, chỉ cho phép một nhóm nhất định đọc và từ chối tất cả các quyền truy cập khác - vấn đề với ví dụ này là một khi yêu cầu đối với một nhóm có quyền truy cập ghi, người dùng / nhóm / khác không thành công với điều đó. Câu trả lời cho cả hai là sử dụng ACL và không biện minh cho IMHO, sự tồn tại của quyền sở hữu.

NB Tôi đã tinh chỉnh câu hỏi này sau khi đóng câu hỏi trong superuser.com .

EDIT đã sửa "nhưng sơ đồ nhóm / chủ sở hữu sẽ không đủ" thành "... nhóm / khác ...".

Lịch sử

Ban đầu, Unix chỉ có quyền cho người dùng sở hữu và cho những người dùng khác: không có nhóm. Xem tài liệu của Unix phiên bản 1, đặc biệt chmod(1). Vì vậy, khả năng tương thích ngược, nếu không có gì khác, yêu cầu quyền cho người dùng sở hữu.

Các nhóm đến sau. ACL cho phép liên quan đến nhiều nhóm trong các quyền của tệp xuất hiện muộn hơn nhiều.

Sức mạnh biểu cảm

Có ba quyền cho một tệp cho phép các quyền chi tiết hơn so với chỉ có hai, với chi phí rất thấp (thấp hơn rất nhiều so với ACL). Ví dụ: một tệp có thể có chế độ rw-r-----: chỉ có thể ghi bởi người dùng sở hữu, có thể đọc được bởi một nhóm.

Một trường hợp sử dụng khác là các tệp thực thi setuid chỉ được thực thi bởi một nhóm. Ví dụ: một chương trình có chế độ rwsr-x---thuộc sở hữu root:adminchỉ cho phép người dùng trong adminnhóm chạy chương trình đó với quyền root.

Có những quyền mà lược đồ này không thể diễn tả là một đối số khủng khiếp đối với nó. Tiêu chí áp dụng là, có đủ các trường hợp rõ ràng phổ biến để biện minh cho chi phí không? Trong trường hợp này, chi phí là tối thiểu, đặc biệt là đưa ra các lý do khác cho người dùng / nhóm / bộ ba khác.

Sự đơn giản

Có một nhóm cho mỗi người dùng có một chi phí quản lý nhỏ nhưng không đáng kể. Điều tốt là trường hợp cực kỳ phổ biến của một tệp riêng không phụ thuộc vào điều này. Một ứng dụng tạo tệp riêng (ví dụ: chương trình gửi email) biết rằng tất cả những gì cần làm là cung cấp cho tệp ở chế độ 600. Không cần phải truy cập cơ sở dữ liệu nhóm tìm nhóm chỉ chứa người dùng - và Phải làm gì nếu không có nhóm đó hoặc nhiều hơn một?

Đến từ một hướng khác, giả sử bạn nhìn thấy một tệp và bạn muốn kiểm tra các quyền của nó (tức là kiểm tra xem chúng có phải là những gì chúng cần). Sẽ dễ dàng hơn rất nhiều khi bạn có thể truy cập vào người dùng, chỉ có thể truy cập vào người dùng, tốt hơn, tiếp theo so với khi bạn cần theo dõi các định nghĩa nhóm. (Sự phức tạp như vậy là nguyên nhân của các hệ thống sử dụng nhiều tính năng nâng cao như ACL hoặc khả năng.)

Tính trực giao

Mỗi quy trình thực hiện truy cập hệ thống tập tin như một người dùng cụ thể và một nhóm cụ thể (với các quy tắc phức tạp hơn trên các đơn vị hiện đại, hỗ trợ các nhóm bổ sung). Người dùng được sử dụng cho rất nhiều thứ, bao gồm kiểm tra root (uid 0) và quyền phân phối tín hiệu (dựa trên người dùng). Có một sự đối xứng tự nhiên giữa việc phân biệt người dùng và nhóm trong quyền truy cập quy trình và phân biệt người dùng và nhóm trong quyền hệ thống tệp.

Đây là thiết kế có chủ ý hay một bản vá? Đó là - các quyền của chủ sở hữu / nhóm được thiết kế và tạo cùng với một số lý do hay họ đã lần lượt từng người một để trả lời một nhu cầu?

Người dùng / nhóm / quyền khác trên một tệp là một phần của thiết kế Unix gốc.

Có một kịch bản trong đó lược đồ người dùng / nhóm / chương trình khác hữu ích nhưng lược đồ nhóm / chủ sở hữu sẽ không đủ?

Vâng, hầu như mọi kịch bản tôi có thể tưởng tượng nơi an ninh và kiểm soát truy cập là quan trọng.

Ví dụ: Bạn có thể muốn cung cấp một số tệp nhị phân / tập lệnh trên quyền truy cập chỉ thực thi của hệ thống othervà giữ quyền truy cập đọc / ghi bị hạn chế root.

Tôi không chắc bạn nghĩ gì về mô hình cấp phép hệ thống tệp chỉ có quyền của chủ sở hữu / nhóm. Tôi không biết làm thế nào bạn có thể có một hệ điều hành an toàn mà không có sự tồn tại của một otherdanh mục.

EDIT: Giả sử bạn có nghĩa là group/otherquyền ở đây là tất cả những gì cần thiết, sau đó tôi khuyên bạn nên nghĩ ra một số cách để quản lý khóa mật mã hoặc cách mà chỉ người dùng phù hợp mới có thể truy cập vào hộp thư của họ. Có những trường hợp khóa riêng có thể cần user:userquyền sở hữu nghiêm ngặt nhưng các trường hợp khác có ý nghĩa để trao user:groupquyền sở hữu.

các tệp riêng tư - rất dễ dàng có được bằng cách tạo một nhóm cho mỗi người dùng, một việc thường được thực hiện như trong nhiều hệ thống.

Cứ cho rằng việc này dễ dàng thực hiện, nhưng nó cũng dễ thực hiện với sự tồn tại của một othernhóm ...

chỉ cho phép chủ sở hữu (ví dụ: dịch vụ hệ thống) ghi vào tệp, chỉ cho phép một nhóm nhất định đọc và từ chối tất cả các quyền truy cập khác - vấn đề với ví dụ này là một khi yêu cầu đối với một nhóm có quyền truy cập ghi, người dùng / nhóm / khác thất bại với điều đó. Câu trả lời cho cả hai là sử dụng ACL và không biện minh cho IMHO, sự tồn tại của quyền sở hữu.

Tôi đã nhấn mạnh một phần của tuyên bố của bạn dường như nhắc lại quan điểm của tôi về sự cần thiết hợp lý cho một otherdanh mục trong các quyền của hệ thống tệp Unix.

Một thiết kế hệ thống tập tin như bạn dường như đang suy nghĩ (từ những gì tôi có thể nói) sẽ không an toàn hoặc khó sử dụng. Unix được thiết kế bởi một số người rất thông minh và tôi nghĩ rằng mô hình của họ mang lại sự cân bằng tốt nhất có thể về bảo mật và tính linh hoạt.

Đây là thiết kế có chủ ý hay một bản vá? Đó là - các quyền của chủ sở hữu / nhóm được thiết kế và tạo cùng với một số lý do hay họ đã lần lượt đến để trả lời một nhu cầu?

Có, đây là một thiết kế có chủ ý đã có mặt trong UNIX từ những ngày đầu. Nó được thực hiện trên các hệ thống mà bộ nhớ được đo bằng KB và CPU cực kỳ chậm theo tiêu chuẩn ngày nay. Kích thước và tốc độ của những cái nhìn như vậy rất quan trọng. ACL sẽ cần nhiều không gian hơn và chậm hơn. Về mặt chức năng, everyonenhóm được đại diện bởi các cờ bảo mật khác.

Có một kịch bản trong đó lược đồ người dùng / nhóm / chương trình khác hữu ích nhưng lược đồ nhóm / chủ sở hữu sẽ không đủ?

Quyền tôi thường sử dụng để truy cập tệp là: (Tôi đang sử dụng các giá trị bit để đơn giản và vì đó là cách tôi thường đặt chúng.)

• 600hoặc 400: Người dùng chỉ truy cập (và có, tôi cấp quyền truy cập chỉ đọc cho người dùng).
• 640hoặc 660: Truy cập người dùng và nhóm.
• 644, 666Hoặc 664: dùng, nhóm, và truy cập khác. Bất kỳ sơ đồ cấp phép hai cấp chỉ có thể xử lý hai trường hợp này. Thứ ba sẽ yêu cầu ACL.

Đối với các thư mục và chương trình tôi thường sử dụng:

• 700hoặc 500: Người dùng chỉ truy cập
• 750hoặc 710: Chỉ truy cập nhóm
• 755, 777, 775, Hoặc 751: dùng, nhóm, và truy cập khác. Nhận xét tương tự như áp dụng cho các tập tin.

Trên đây là những danh sách được sử dụng phổ biến nhất, nhưng không phải là danh sách đầy đủ các thiết lập quyền mà tôi sử dụng. Các quyền trên kết hợp với một nhóm (đôi khi có một bit nhóm dính trên các thư mục) đã được sử dụng trong tất cả các trường hợp mà tôi có thể đã sử dụng ACL.

Như đã lưu ý ở trên, rất dễ dàng để liệt kê sự cho phép trong một danh sách thư mục. Nếu ACL không được sử dụng, tôi có thể kiểm tra quyền truy cập chỉ với một danh sách thư mục. Khi tôi làm việc với các hệ thống dựa trên ACL, tôi thấy rất khó để xác minh hoặc kiểm tra quyền.

Người dùng / nhóm / hệ thống cấp phép khác được thiết kế trước khi ACL được phát minh. Nó quay trở lại những ngày đầu của UNIX, vì vậy bạn không thể nói vấn đề cần được giải quyết bằng ACL. Ngay cả khi khái niệm về ACL có vẻ rõ ràng, thì nó cũng sẽ liên quan đến một lượng chi phí đáng kể [trong ngày] để lưu trữ và quản lý một lượng thông tin cấp phép khác nhau với mỗi tệp, thay vì một lượng cố định.

Sử dụng ACL cho mọi thứ cũng có nghĩa là bạn không có một tập hợp con được xác định rõ về thông tin cấp phép có thể được hiển thị "trong nháy mắt". Đầu ra cho ls -lthấy các quyền (người dùng / nhóm / người khác) tiêu chuẩn, tên của người dùng và nhóm và một ký hiệu bổ sung (ví dụ +hoặc @ký hiệu) trên các mục có ACL được liên kết với chúng, tất cả trong một dòng. Hệ thống của bạn sẽ yêu cầu nó xác định các nhóm "hai nhóm hàng đầu" trong ACL để cung cấp chức năng tương đương.

Là một điểm bổ sung, một tệp vẫn cần phải có chủ sở hữu trong mô hình UNIX vì các ACL UNIX không cung cấp cho ai được phép sửa đổi ACL.