Tại sao chmod (1) trong nhóm ảnh hưởng đến mặt nạ ACL?

Tôi đang cố gắng để hiểu hành vi Unix này (mà tôi tình cờ đang thử nghiệm trên Ubuntu 11.10):

$ touch foo
$ setfacl -m u:nobody:rwx foo
$ getfacl foo
# file: foo
# owner: michael
# group: michael
user::rw-
user:nobody:rwx
group::rw-
mask::rwx
other::r--

$ chmod g-rw foo
$ getfacl foo
# file: foo
# owner: michael
# group: michael
user::rw-
user:nobody:rwx         #effective:--x
group::rw-          #effective:---
mask::--x
other::r--

Lưu ý rằng lệnh chmod (1) đã cập nhật mặt nạ ACL. Lý do tại sao điều này xảy ra?

Trang web của SunOS có nội dung như sau:

Nếu bạn sử dụng lệnh chmod (1) để thay đổi quyền của chủ sở hữu nhóm tệp trên một tệp có mục ACL, cả quyền của chủ sở hữu nhóm tệp và mặt nạ ACL đều được thay đổi thành quyền mới. Xin lưu ý rằng các quyền của mặt nạ ACL mới có thể thay đổi các quyền hiệu quả cho những người dùng và nhóm bổ sung có các mục ACL trên tệp.

Tôi hỏi bởi vì nó sẽ thuận tiện cho tôi nếu chmod (1) không có hành vi này. Tôi hy vọng rằng bằng cách hiểu tại sao nó làm những gì nó làm, tôi có thể thiết kế tốt hơn cách tôi thiết lập quyền hệ thống tập tin.

Sẽ không thuận tiện cho bạn nếu chmod()không có hành vi này.

Nó sẽ rất bất tiện, bởi vì những thứ mà mọi người thường mong đợi để làm việc trên Unix sẽ bị phá vỡ. Hành vi này phục vụ bạn tốt, bạn đã biết nhưng nó biết.

Thật đáng tiếc khi IEEE 1003.1e không bao giờ trở thành một tiêu chuẩn và đã bị rút lại vào năm 1998. Trong thực tế, mười bốn năm, đó là một tiêu chuẩn mà một loạt các hệ điều hành - từ Linux thông qua FreeBSD đến Solaris - thực sự được thực hiện.

Bản thảo làm việc số 17 của IEEE 1003.1e làm cho việc đọc thú vị và tôi khuyên bạn nên đọc nó. Trong phụ lục B § 23.3, nhóm làm việc cung cấp một cơ sở chi tiết, gồm tám trang, cho cách thức hơi phức tạp mà POSIX ACL hoạt động đối với các S_IRWXGcờ cho phép của nhóm cũ . (Đáng lưu ý rằng những người TRUSIX đã cung cấp nhiều phân tích tương tự mười năm trước.) Tôi sẽ không sao chép tất cả ở đây. Đọc cơ sở lý luận trong dự thảo tiêu chuẩn để biết chi tiết. Đây là một précis rất ngắn gọn :

• Hướng dẫn sử dụng SunOS là sai. Nó nên đọc

  Nếu bạn sử dụng các chmod(1)lệnh để thay đổi các điều khoản chủ sở hữu nhóm tập tin vào một tập tin với mục ACL, hoặc các điều khoản chủ sở hữu nhóm tập tin hoặc mặt nạ ACL được thay đổi để các điều khoản mới.

  Đây là hành vi mà bạn có thể thấy xảy ra , bất chấp những gì trang hướng dẫn hiện tại nói, trong câu hỏi của bạn. Đó cũng là hành vi được chỉ định bởi tiêu chuẩn POSIX dự thảo. Nếu tồn tại một CLASS_OBJthuật ngữ ACL_MASKkiểm soát truy cập (của Sun và TRUSIX ), các bit nhóm của một chmod()tập hợp, nếu không, chúng sẽ đặt GROUP_OBJmục kiểm soát truy cập.

• Nếu đây không phải là trường hợp, các ứng dụng đã làm nhiều thứ tiêu chuẩn khác nhau với `chmod ()`, hy vọng nó hoạt động như `chmod ()` theo truyền thống hoạt động trên các Unix không ACL cũ, sẽ để lại lỗ hổng bảo mật hoặc xem những gì họ nghĩ rằng sẽ bị lỗ hổng bảo mật:

  • Các ứng dụng Unix truyền thống hy vọng có thể từ chối tất cả quyền truy cập vào một tệp, được đặt tên là pipe, thiết bị hoặc thư mục chmod(…,000). Với sự hiện diện của ACL, điều này chỉ tắt tất cả các quyền của người dùng và nhóm nếu S_IRWXGbản đồ cũ thành CLASS_OBJ. Nếu không có điều này, việc thiết lập quyền truy cập tệp cũ 000sẽ không ảnh hưởng đến bất kỳ USERhoặc GROUPmục nào và những người dùng khác sẽ vẫn có quyền truy cập vào đối tượng.

    Thay đổi tạm thời các bit cho phép của tệp thành không có quyền truy cập chmod 000và sau đó thay đổi lại chúng là một cơ chế khóa tệp cũ, được sử dụng trước khi Unix có được các cơ chế khóa tư vấn, như bạn có thể thấy - ngày nay mọi người vẫn sử dụng .

  • Các tập lệnh Unix truyền thống hy vọng có thể chạy chmod go-rwxvà kết thúc chỉ với chủ sở hữu của đối tượng có thể truy cập vào đối tượng. Một lần nữa - như bạn có thể thấy - đây vẫn là sự khôn ngoan nhận được mười hai năm sau. Và một lần nữa, điều này không làm việc trừ khi già S_IRWXGbản đồ để CLASS_OBJnếu nó tồn tại, bởi vì nếu không có chmodlệnh sẽ không tắt bất kỳ USERhoặc GROUPkiểm soát truy cập mục, dẫn đến người sử dụng khác hơn là chủ sở hữu và nhóm giữ lại quyền truy cập vào cái gì mà không sở hữu là dự kiến chỉ có thể truy cập cho chủ sở hữu.

  • Một hệ thống trong đó các bit quyền được tách biệt và andphù hợp với ACL sẽ yêu cầu các cờ cấp phép tệp rwxrwxrwxtrong hầu hết các trường hợp, điều này sẽ gây nhầm lẫn cho nhiều ứng dụng Unix phàn nàn khi chúng thấy những gì chúng nghĩ là có thể ghi được trên thế giới đồ đạc.

    Một hệ thống trong đó các bit quyền được tách biệt và orphù hợp với ACL sẽ có chmod(…,000)vấn đề được đề cập trước đó.

đọc thêm

• Winfried Trümper (1999-02-28). Tóm tắt về Posix.1e
• Ủy ban Tiêu chuẩn Ứng dụng Di động của Hiệp hội Máy tính IEEE (Tháng 10 năm 1997). Dự thảo Tiêu chuẩn cho Công nghệ thông tin Giao diện hệ điều hành di động (POSIX) Tập 1: Giao diện chương trình ứng dụng hệ thống (API) - Sửa đổi #: Giao diện bảo vệ, kiểm toán và kiểm soát [Ngôn ngữ C] IEEE 1003.1e. Dự thảo 17.
• Craig Rubin (1989-08-18). Cơ sở lý luận để chọn tính năng danh sách điều khiển truy cập cho hệ thống Unix . NCSC-TG-020-A. Nhà xuất bản DIane. SỐ TIẾNG ANH88105548.

Hành vi này chỉ áp dụng cho các mục ACIX POSIX. Lý do ở đây là nếu bạn có một thư mục và bên trong thư mục đó tồn tại một tệp, bạn có thể acl dưới dạng rwx (ví dụ) thư mục và tệp. Nếu các quyền của nhóm là rw- (mà chúng có thể là một kịch bản điển hình) thì mặt nạ sẽ cung cấp cho acl các quyền hiệu quả của rw- mặc dù ACL biểu thị rõ ràng rwx.

Mặt khác, thư mục gần như luôn luôn là + x có quyền truy cập mặt nạ ACL hiệu quả cũng cho phép + x.

Tóm lại, mặt nạ này về cơ bản được sử dụng để phân biệt quyền giữa các tệp và thư mục cho bộ POSIX ACL để tệp không thể thực thi được khi không nên bình thường.