Mối quan hệ nào ràng buộc mặt nạ ACL và quyền nhóm tiêu chuẩn trên một tệp?


17

Đầu tiên tôi tạo một tệp và kiểm tra các quyền và tiêu chuẩn ACL của nó:

$ touch file; ls -l file; getfacl file
-rw-r--r-- 1 user user 0 Jul 30 16:26 file
# file: file
# owner: user
# group: user
user::rw-
group::r--
other::r--

Sau đó, tôi đặt mặt nạ ACL trên tệp và kiểm tra lại các quyền và tiêu chuẩn ACL của nó:

$ setfacl -m mask:rwx file
$ ls -l file; getfacl file
-rw-rwxr--+ 1 user user 0 Jul 30 16:26 file
# file: file
# owner: user
# group: user
user::rw-
group::r--
mask::rwx
other::r--

Lưu ý rằng cùng với quyền của nhóm mặt nạ ACL trên tệp cũng thay đổi.

  1. Mối liên hệ nào tồn tại giữa mặt nạ ACL và quyền nhóm tiêu chuẩn?
  2. Lý do cho việc ghép mặt nạ ACL và quyền nhóm tệp là gì? Logic gì nằm đằng sau nó?

Các bản phân phối trong câu hỏi là Debian Linux 7.6 và CentOS 7


BIÊN TẬP

Tại thời điểm này tôi chỉ muốn chia sẻ một số phát hiện của tôi mà tôi đã đưa ra trong khi nghiên cứu mối quan hệ giữa các quyền của nhóm tệp tiêu chuẩn và mặt nạ ACL. Dưới đây là những quan sát thực nghiệm tôi tìm thấy:

  1. Mặt nạ ACL có thể được thay đổi:

    1. bằng cách trực tiếp thiết lập nó bằng setfacl -m m:<perms>lệnh;
    2. bằng cách thay đổi quyền của nhóm tệp bằng chmodlệnh (nếu mặt nạ ACL đã có sẵn; nó có thể không xuất hiện vì nó là tùy chọn nếu không có quyền ACL của người dùng hoặc nhóm được đặt tên trên tệp);
    3. bằng cách thêm mục nhập ACL của người dùng hoặc nhóm được đặt tên (mặt nạ sẽ được tự động tính toán lại).
  2. Mặt nạ sẽ thực thi quyền truy cập tối đa (nếu có các mục ACL có quyền vượt quá quyền truy cập mặt nạ ACL) chỉ khi mặt nạ được đặt trực tiếp bởi setfacl hoặc bằng cách sửa đổi quyền của nhóm tệp bằng chmod (không được tính toán tự động). Mọi thay đổi đối với các mục ACL sẽ kích hoạt tính toán lại tự động mặt nạ ACL và tắt "chế độ thực thi" một cách hiệu quả.

  3. Có một số tác dụng phụ ảnh hưởng ngầm đến quyền của nhóm tệp tiêu chuẩn khi sử dụng ACL:

    1. Mục nhập ACL của người dùng hoặc nhóm được đặt tên được áp dụng cho một tệp có thể thay đổi mặt nạ ACL (tăng quyền của nó) và do đó, quyền của nhóm tệp hiệu quả. Ví dụ: nếu bạn, với tư cách là chủ sở hữu tệp, có quyền "rw-r - r-- jim student" được đặt trên đó và bạn cũng cấp quyền rw cho người dùng "jack", bạn cũng sẽ cấp quyền rw cho bất kỳ ai từ nhóm "sinh viên".
    2. Mặt nạ ACL nghiêm ngặt hơn (ít quyền hơn) có thể xóa vĩnh viễn quyền truy cập nhóm tệp tiêu chuẩn tương ứng. Ví dụ: nếu bạn có một tệp có quyền truy cập nhóm tệp chuẩn rw và bạn áp dụng mặt nạ ACL chỉ đọc cho tệp thì quyền của nhóm sẽ giảm xuống chỉ đọc. Sau đó, nếu bạn xóa tất cả các mục ACL mở rộng (bằng setfacl -blệnh), các quyền của nhóm sẽ ở chế độ chỉ đọc. Điều này chỉ áp dụng cho mặt nạ ACL chặt chẽ hơn, mặt nạ ACL mềm hơn (nhiều quyền hơn) không thay đổi vĩnh viễn quyền của nhóm tệp gốc sau khi bị xóa.

Tôi nghĩ rằng bạn có thể mất các trang sau đây để tham khảo, www-uxsup.csx.cam.ac.uk/pub/doc/suse/sles9/adminguide-sles9/...
kundy

Câu trả lời:


11

Sẽ không có nghĩa gì nếu các quyền của tệp unix không đồng ý với mục nhập acl và ngược lại. Theo đó, trang hướng dẫn ( acl(5)) cho biết những gì bạn yêu cầu:

ĐÚNG CÁCH GIỮA ACL ENTRIES VÀ FITS PERMISSION BITS

Các quyền được xác định bởi ACL là một siêu quyền của các quyền được chỉ định bởi các bit quyền của tệp.

Có sự tương ứng giữa chủ sở hữu tệp, nhóm và các quyền khác và các mục nhập ACL cụ thể: quyền của chủ sở hữu tương ứng với các quyền của mục nhập ACL_USER_OBJ. Nếu ACL có mục ACL_MASK, quyền của nhóm tương ứng với quyền của mục ACL_MASK. Mặt khác, nếu ACL không có mục ACL_MASK, các quyền của nhóm tương ứng với các quyền của mục ACL_GROUP_OBJ. Các quyền khác tương ứng với các quyền của mục nhập ACL_OTHER_OBJ.

Chủ sở hữu tệp, nhóm và các quyền khác luôn khớp với các quyền của mục nhập ACL tương ứng. Việc sửa đổi các bit quyền của tệp dẫn đến việc sửa đổi các mục ACL được liên kết và sửa đổi các mục ACL này dẫn đến việc sửa đổi các bit cho phép của tệp.

Phụ lục trả lời thảo luận:

Lý do cho việc ghép mặt nạ ACL và quyền nhóm tệp là gì? Logic gì nằm đằng sau nó?

Một lời giải thích tốt là ở đây . Về bản chất, mặt nạ là một

[...] Giới hạn trên của các quyền mà bất kỳ mục nào trong lớp nhóm sẽ cấp.

Thuộc tính ràng buộc trên này đảm bảo rằng các ứng dụng POSIX.1 không biết về ACL sẽ không đột ngột và bất ngờ bắt đầu cấp quyền bổ sung sau khi ACL được hỗ trợ.

Trong các ACL tối thiểu, các quyền của nhóm nhóm giống hệt với các quyền của nhóm sở hữu. Trong các ACL mở rộng, lớp nhóm có thể chứa các mục nhập cho người dùng hoặc nhóm bổ sung. Điều này dẫn đến một vấn đề: một số trong các mục bổ sung này có thể chứa các quyền không có trong mục nhập nhóm sở hữu, do đó, quyền sở hữu mục nhập nhóm có thể khác với quyền của nhóm nhóm.

Vấn đề này được giải quyết bằng đức tính của mục mặt nạ. Với ACL tối thiểu, quyền nhóm lớp ánh xạ tới quyền truy cập nhóm sở hữu. Với ACL mở rộng, quyền nhóm lớp ánh xạ tới quyền truy cập mặt nạ, trong khi mục nhập nhóm sở hữu vẫn xác định quyền sở hữu nhóm. Ánh xạ của các quyền lớp nhóm không còn là hằng số.


Những gì bạn đang nói áp dụng cho đầu ra getfacl sau: user :: rw- group :: r-- other :: r-- . 3 dòng đó sẽ thay đổi nếu bạn sử dụng chmodlệnh để thay đổi quyền tiêu chuẩn và ngược lại khi bạn thực thi, giả sử getfacl -m u:someuser:rwx, quyền tệp chuẩn cho chủ sở hữu tệp sẽ thay đổi và thay đổi sẽ được phản ánh trong ls -lđầu ra. Điều đó hoàn toàn đúng, nhưng tôi không thấy nó trả lời câu hỏi của tôi như thế nào
golem

xem bản chỉnh sửa của tôi để biết toàn bộ câu chuyện
phản hồi

1
Câu trả lời được chỉnh sửa của bạn nói rằng có một sự kết hợp giữa các quyền của nhóm tệp và mặt nạ ACL theo thiết kế. Câu hỏi về lý do của việc ghép mặt nạ ACL và quyền nhóm tệp vẫn còn là gì. Những gì logic đằng sau nó không rõ ràng với tôi.
golem

1
Có thể có ý nghĩa. Nó phụ thuộc vào định nghĩa và thực hiện. Theo định nghĩa tệp Linux ACL, như được triển khai ngay bây giờ, là một siêu quyền của các quyền của tệp tiêu chuẩn, bao gồm chúng. Vì vậy, họ không thể "mâu thuẫn". Đây là một trường hợp sử dụng. Nếu tôi gán quyền rwx cho "người kiểm tra" cho tệp có -rw-r--r-- 1 user userquyền ban đầu , ACL có tên người dùng đó sẽ được chấp nhận và mặt nạ ACL (cùng với quyền của nhóm tệp) cũng sẽ được thay đổi thành rwx. --- [xem bình luận tiếp theo là phần tiếp theo]
golem

1
Bây giờ quyền rwx của "người kiểm tra" có mâu thuẫn với -rw-rwxr-- 1 user userquyền mới của tập tin hay không? Làm thế nào để bạn xác định mâu thuẫn? Bằng cách so sánh các quyền ACL của người kiểm tra với quyền của nhóm tệp chuẩn? Logic nào khiến bạn so sánh quyền của nhóm với quyền của người dùng? Không phải họ là những thực thể khác nhau sao? Nó không phải là phản trực giác? Nó có thể là rõ ràng đối với bạn nhưng tôi vẫn đang cố gắng để nắm bắt nó.
golem

3

Cuối cùng tôi đã hiểu chính xác những gì đang xảy ra khi tôi thấy liên kết này Xử lý ACL

Cụ thể, mặt nạ đó về cơ bản thay thế và hoạt động để thay thế NAMED USER và tất cả các quyền của NHÓM. Điều này có nghĩa là nếu bạn:

  1. điều chỉnh mặt nạ, bạn thay đổi quyền tối đa của nhóm,
  2. nếu bạn thay đổi bất kỳ quyền của nhóm với mặt nạ hiện diện, mặt nạ sẽ có quyền tối đa của nhóm trong tất cả các quyền của nhóm
  3. quyền đọc, ghi và thực thi nhóm được xác định dựa trên mặt nạ, nếu có

nhập mô tả hình ảnh ở đây

Hy vọng điều này sẽ giúp.


Có một lời giải thích rất hay về mặt nạ trên trang bạn đã giới thiệu (trích dẫn từ phần 27.3.3. Thư mục với ACL truy cập ): mặt nạ xác định quyền truy cập hiệu quả tối đa cho tất cả các mục trong lớp nhóm. Điều này bao gồm người dùng được đặt tên, nhóm được đặt tên và nhóm sở hữu. .
patryk.beza

-1

Logic gì nằm đằng sau nó?

Logic hoàn toàn bị phá vỡ và do đó POSIX ACL là vô nghĩa và vô nghĩa.

Nếu họ nhằm duy trì khả năng tương thích với các ứng dụng mà không có khái niệm về ACL trừ tiêu chuẩn nguyên thủy UNIX' ugo "mô hình, họ thực sự đã thất bại ngay từ đầu vì bây giờ mọi ứng quyền Clears nhóm được thu hồi có hiệu quả truy cập thêm bởi ACL.

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.