giải thích về chown (1) thông số POSIX

Thông số POSIX cho chowntiện ích đề cập trong phần cơ sở của nó về chown user:groupcú pháp (trước đây chown user.group) (nhấn mạnh của tôi):

Phương pháp 4.3 BSD chỉ định cả chủ sở hữu và nhóm được bao gồm trong tập POSIX.1-2008 này vì:

• Có những trường hợp không thể đạt được điều kiện kết thúc mong muốn bằng cách sử dụng các tiện ích chgrp và chown (chỉ thay đổi ID người dùng). (Nếu chủ sở hữu hiện tại không phải là thành viên của nhóm mong muốn và chủ sở hữu mong muốn không phải là thành viên của nhóm hiện tại, hàm chown () có thể không thành công trừ khi cả chủ sở hữu và nhóm được thay đổi cùng một lúc.)

Tôi nghĩ rằng user:groupcú pháp là một điều thuận tiện. Bây giờ ở trên ngụ ý có những điều bạn có thể làm với chown user:groupmà bạn không thể làm vớichgrp group; chown user

Bây giờ văn bản đó không có ý nghĩa với tôi. Trong 4.3BSD, chỉ root mới có thể thay đổi chủ sở hữu một tệp vì vậy trong mọi trường hợp, không có hạn chế nào trong những gì anh ta có thể làm.

SysV và một vài hệ thống khác cho phép (hoặc được sử dụng để cho phép) chủ sở hữu tệp thay đổi người dùng và nhóm tệp thành bất kỳ thứ gì, nhưng ngay cả trong các hệ thống đó, văn bản trên không có ý nghĩa với tôi. Được rồi, nếu người ta làm một chown someone-else the-file, người ta không thể làm chgrp something-else the-filesau đó vì người đó không còn là chủ sở hữu của tệp, nhưng không có gì ngăn cản anh ta / cô ta làm điều chgrpđầu tiên (là chủ sở hữu của tệp) và chownsau đó, và đó không phải là văn bản trên là chính xác nói.

Tôi không hiểu chủ sở hữu và mong muốn không phải là thành viên của nhóm hiện tại có liên quan gì đến vấn đề.

Vì vậy, các điều kiện mà hàm chown () có thể thất bại trừ khi cả chủ sở hữu và nhóm được thay đổi cùng một lúc , và trên hệ thống nào?

Hệ thống con Microsoft Interix Unix (hiện đã nghỉ hưu) cho nhân NT của nó xử lý hơi khác với quyền của người dùng và nhóm so với một số người khác làm:

Thông tin người dùng và nhóm được lưu trữ trong cơ sở dữ liệu Bảo mật truy cập . Cả người dùng và nhóm được lưu trữ trong cùng một cơ sở dữ liệu, nhưng tên nhóm và tên người dùng phải là duy nhất; không nhóm nào có thể có tên người dùng và ngược lại. (Cơ sở dữ liệu này thay thế các tệp /etc/passwdvà /etc/groupstệp trong UNIX.) Người dùng và nhóm được tạo bằng phương pháp Windows thích hợp (Trình quản lý người dùng, Người dùng và Máy tính Active Directory hoặc Người dùng và nhóm cục bộ) hoặc bằng net userlệnh Win32 . (Ví dụ tập lệnh shell để tạo và xóa người dùng được bao gồm trong thư mục /usr/examples/admin.) Người dùng có thể thuộc nhiều nhóm.

Dưới đây là một số trích đoạn thủ công cụ thể hơn:

Trong Windows, người dùng hoặc nhóm có thể sở hữu một đối tượng. Điều này khác với UNIX, trong đó chỉ có người dùng sở hữu một đối tượng.

Windows xác định tất cả người dùng và nhóm bên trong bằng cách sử dụng mã định danh bảo mật (SID) . Một thuật toán băm tạo ra các giá trị SID là duy nhất; không có hai người dùng hoặc nhóm sẽ có cùng SID.

Người dùng và nhóm có quyền truy cập vào một đối tượng được xác định bởi SID của họ. Tất cả các đối tượng có thể được bảo mật bởi Windows đều có danh sách kiểm soát truy cập tùy ý (DACL), bao gồm các mục riêng biệt được gọi là mục kiểm soát truy cập (ACE). Một ACE bao gồm hai thông tin quan trọng: SID người dùng hoặc nhóm và mô tả về mức độ truy cập của từng người dùng hoặc nhóm đối với một đối tượng.

CHGRP

... Thay đổi ID nhóm cho tệp ... người dùng gọi chgrp (1) phải thuộc về nhóm được chỉ định và là chủ sở hữu của tệp hoặc có các đặc quyền phù hợp.

CHOWN

... Các toán hạng chủ sở hữu và nhóm đều là tùy chọn; tuy nhiên, người ta phải được chỉ định. Nếu toán hạng nhóm được chỉ định, nó phải được bắt đầu bằng dấu hai chấm (:).

Chủ sở hữu có thể được chỉ định bằng ID người dùng số hoặc tên người dùng. Nếu tên người dùng cũng là ID người dùng số, toán hạng được sử dụng làm tên người dùng. Nhóm có thể là ID nhóm số hoặc tên nhóm. Nếu tên nhóm cũng là ID nhóm số, toán hạng được sử dụng làm tên nhóm.

Vì lý do bảo mật, quyền sở hữu một tệp chỉ có thể được thay đổi bởi một quy trình với các đặc quyền phù hợp.

Khi tôi đọc điều đó có nghĩa là nếu tài khoản người dùng của bạn thuộc nhóm Windows có đủ đặc quyền để sửa đổi các quyền của tệp thuộc sở hữu của nhóm đó, thì có thể sử dụng hiệu quả chgrptệp đó ngoài tầm kiểm soát của tài khoản người dùng của bạn. Số tiền này kiểm soát ít hơn bạn có thể có chownvà user:groupcác tham số rõ ràng . Trong bối cảnh đó mà không có khả năng khai báo user: và :group bạn không bao giờ có thể đạt được kết quả tương tự như khác.

Đây là một liên kết đến một cái nhìn chi tiết về cách Interix tương tác với các ACL của Windows với trọng tâm là cách kiến ​​thức đó có thể áp dụng cho các hệ thống tệp Samba trên các biến thể Unix khác.

Đây là một liên kết đến một tài liệu Solaris đã lỗi thời mô tả điều chỉnh rstchownmà ...

Cho biết liệu ngữ nghĩa POSIX cho chown(2)cuộc gọi hệ thống có hiệu lực ...

Rõ ràng, nếu tham số được đặt thành giá trị 0...

... Tắt ngữ nghĩa POSIX mở ra tiềm năng cho các lỗ hổng bảo mật khác nhau. Nó cũng mở ra khả năng người dùng thay đổi quyền sở hữu tệp cho người dùng khác và không thể truy xuất lại tệp mà không có sự can thiệp từ người dùng hoặc quản trị viên hệ thống.

Một tùy chọn như vậy không làm mất hiệu lực tuân thủ POSIX của Solaris . Chỉ cần nó là một tùy chọn đủ điều kiện nó là phù hợp :

Mặc dù tất cả các triển khai tuân thủ POSIX.1-2008 đều hỗ trợ tất cả các tính năng được mô tả bên dưới, có thể có các quy trình cấu hình phụ thuộc vào hệ thống hoặc tệp phụ thuộc vào hệ thống có thể xóa hoặc sửa đổi bất kỳ hoặc tất cả các tính năng này. Cấu hình như vậy không nên được thực hiện nếu cần tuân thủ nghiêm ngặt.

Các hằng số tượng trưng sau đây phải được xác định bằng một giá trị khác -1. Nếu một hằng số được định nghĩa với không có giá trị, các ứng dụng nên sử dụng sysconf(), pathconf()hoặc fpathconf()chức năng, hoặc các getconftiện ích, để xác định các tính năng có mặt trên hệ thống tại thời điểm đó hoặc cho tên đường dẫn đặc biệt trong câu hỏi.

_POSIX_CHOWN_RESTRICTED

Việc sử dụng chown()bị hạn chế trong một quy trình với các đặc quyền phù hợp và chỉ thay đổi ID nhóm của tệp thành ID nhóm hiệu quả của quy trình hoặc một trong các ID nhóm bổ sung của nó.

Hàm chown()hệ thống - là lệnh gọi hệ thống được ghi lại bởi cả hai tiện ích shell chownvà chgrpshell - được chỉ định là không thành công vì nhiều lý do. Trong số đó:

EACCES Quyền tìm kiếm bị từ chối trên một thành phần của tiền tố đường dẫn.

ELOOP Một vòng lặp tồn tại trong các liên kết tượng trưng gặp phải trong quá trình giải quyết đối số đường dẫn.

EPERM ID người dùng hiệu quả không khớp với chủ sở hữu của tệp hoặc quá trình gọi điện không có đặc quyền phù hợp và _POSIX_CHOWN_RESTRICTED chỉ ra rằng đặc quyền đó là bắt buộc.

Tuy nhiên, hành vi cấp quyền sửa đổi quyền cho người dùng không phải root chưa bao giờ là duy nhất đối với Solaris. Có một điều rất tuyệt vời - nếu phần nào ghi ngày tháng - quyền của tệp Unix trong bài đăng trên diễn đàn này, trong đó tác giả tuyên bố:

Ban đầu, Unix cho phép chủ sở hữu tệp cho đi một tệp. Chủ sở hữu tệp có thể thay đổi chủ sở hữu thành người khác. Không có cách nào để người dùng không phải root hoàn tác thao tác này ... BSD [sau đó] đã bị xóa chownkhỏi người dùng không phải root ... [một phần vì] ... nó đã thực hiện hạn ngạch đĩa có thể giới hạn dung lượng đĩa a người dùng có thể có trong một hệ thống tệp ... Người dùng nghịch ngợm có thể cho đi các tệp lớn để theo dõi hạn ngạch.

Ngày nay, không dễ để nói nếu một người không root có thể chownmột tập tin. Nhiều phiên bản của Unix cho phép cả hai hành vi ...

Một điều tốt khác - và gần đây hơn - bài đăng danh sách gửi thư trích dẫn điều này và tiếp tục:

Mặc định với hầu hết các hệ điều hành chownchỉ được giới hạn ở quyền root. Và có một sự đồng thuận rằng nó nên giữ nguyên cách này để xem xét bảo mật. Nếu người dùng không root không thay đổi chủ sở hữu của tệp và bất kỳ bit thực thi nào được bật, thì các bit SUIDvà SGIDphải được xóa. Điều này có thể hoặc không thể xảy ra với root.

Tôi nghĩ rằng đoạn cuối nói nó độc đáo.

Bài viết đó cũng tham khảo CAP_CHOWNđể kiểm soát cơ sở đó trên Linux (điều đó chỉ ảnh hưởng đến POSIX_CHOWN_RESTRICTEDhành vi) . Ngoài ra còn có CAP_FOWNERkhả năng, đó là một chút khác biệt trong hành vi.

Và như bạn đã chỉ ra vào năm 2003 :

Lưu ý rằng ít nhất là trên HPUX, bạn có thể thay đổi chủ sở hữu các tệp của mình ( rootví dụ) ngay cả khi bạn không phải là người dùng được bảo mật ...

... phụ thuộc vào một setprivgrouptham số cấu hình .

Trong mọi trường hợp người dùng không phải root có thể thao tác quyền truy cập tệp, nó có thể hiểu được, như được đề cập trong lý do được trích dẫn trong câu hỏi của bạn, rằng người dùng có thể chownlà một tệp mà người dùng đó sở hữu để người dùng đó sở hữu. Nếu quyền sở hữu nhóm của tệp và các chownnhóm người dùng ing không căn chỉnh thì người dùng sẽ không còn khả năng sửa đổi tệp đó.

Trong kịch bản này chown sau đó chgrp sẽ thất bại vì người dùng sẽ không còn quyền thay đổi quyền của tệp đó, trong khi đó chown user:group- miễn là nhóm nằm trong số người dùng - sẽ thành công.

Có thể có nhiều tình huống thích hợp khác có thể dẫn đến tương tự, có thể bao gồm các bit dính và / hoặc setgid thư mục, hệ thống tệp và / hoặc danh sách kiểm soát truy cập dành riêng cho việc triển khai. Chủ đề này là thú vị, ví dụ. Vô số hoán vị vượt xa khả năng nắm bắt yếu ớt của tôi - đó là lý do tại sao câu trả lời này được đưa ra. Nếu bạn đang đọc điều này, bạn tin rằng nó đáng để cải thiện và bạn tin rằng bạn biết cách - vui lòng làm .

Ngoài ra còn có tài liệu mở rộng về các tác động có thể khác nhau của quyền truy cập tệp, truyền qua cây và các liên kết tượng trưng có thể gây ra lỗi tương tự liên quan đến các ứng dụng -Rgây nhiễu chownở đây:

Từ tiêu đề phần POSIX XRAT Tên miền thứ ba và thứ tư :

Nói chung, người dùng chỉ định tùy chọn cho một hệ thống phân cấp tệp mong muốn hoạt động trên một liên kết đơn, phân cấp vật lý và do đó các liên kết tượng trưng, ​​có thể tham chiếu các tệp bên ngoài phân cấp, bị bỏ qua. Ví dụ: tệp chủ sở hữu chown là một hoạt động khác với cùng một lệnh với tùy chọn -R được chỉ định. Trong ví dụ này, hành vi của lệnh chown owner fileđược mô tả ở đây, trong khi hành vi của chown -Rtệp chủ sở hữu lệnh được mô tả trong miền thứ ba và thứ tư.

... Có một vấn đề bảo mật với mặc định là đi bộ hợp lý. Trong lịch sử, chown -Rtệp người dùng lệnh đã an toàn cho siêu người dùng vì các bit setuid và setgid bị mất khi quyền sở hữu tệp bị thay đổi. Nếu việc đi bộ là hợp lý, việc thay đổi quyền sở hữu sẽ không còn an toàn vì người dùng có thể đã chèn một liên kết tượng trưng chỉ vào bất kỳ tệp nào trong cây. Một lần nữa, điều này đòi hỏi phải bổ sung tùy chọn cho các lệnh thực hiện chuyển đổi thứ bậc để không gián tiếp thông qua các liên kết tượng trưng và các kịch bản lịch sử thực hiện các bước đi đệ quy sẽ ngay lập tức trở thành vấn đề bảo mật. Mặc dù điều này chủ yếu là một vấn đề đối với các quản trị viên hệ thống, tốt hơn là không có các mặc định khác nhau cho các lớp người dùng khác nhau.

...

Trong 4.3 BSD, chgrptrong quá trình duyệt cây đã thay đổi nhóm liên kết tượng trưng, ​​không phải mục tiêu. Các liên kết tượng trưng trong 4.4 BSD không có chủ sở hữu, nhóm, chế độ hoặc các thuộc tính tệp hệ thống UNIX tiêu chuẩn khác.

Và từ chgrptrang POSIX, có điều này chỉ ra một -Rhành động ngụy biện không hoàn chỉnh có thể xảy ra , hoặc ít nhất là với những gì đã từng là:

Các phiên bản System V và BSD sử dụng các mã trạng thái thoát khác nhau. Một số triển khai đã sử dụng trạng thái thoát như là một số lượng lỗi xảy ra; thực hành này là không thể thực hiện được vì nó có thể vượt quá phạm vi của các giá trị trạng thái thoát hợp lệ. Các nhà phát triển tiêu chuẩn đã chọn che dấu những điều này bằng cách chỉ định 0 và> 0 làm giá trị thoát.

Giả định 1: các quy tắc để xác định xem chownthành công có kiểm tra độc lập các bộ phận người dùng và nhóm mục tiêu hay không, tức là chúng có dạng user_condition(target_uid, other_environment_parameters) && group_condition(target_gid, other_environment_parameters).

Giả định 2: chown(file, -1, -1)thành công.

Giả định 3: các quy tắc để xác định xem chownthành công không phụ thuộc vào nhóm mà tập tin hiện đang thuộc về nhóm nào.

Hệ quả: nếu chown(file, uid, gid)thành công thì cũng vậy chown(file, -1, gid) && chown(file, uid, -1).

Tôi không biết về một biến thể Unix sẽ vi phạm bất kỳ giả định nào trong số này, chúng có vẻ khá an toàn.

Câu này có vẻ như một cái gì đó mà ai đó trong ủy ban đã nói khi họ mệt mỏi sau nhiều giờ tranh luận có bao nhiêu lựa chọn có thể phù hợp với đầu pscuộc gọi - hoặc thư ký đã dịch sai - và không ai bị bắt trong khi xem xét. Rốt cuộc, có những lý do tốt khác để cho phép người dùng và nhóm được tự động thay đổi, bao gồm cả lý do hiệu suất cũng được trích dẫn trong lý do POSIX, cũng như tính nguyên tử (ah, nếu chỉ có một cuộc gọi duy nhất để thay đổi quyền sở hữu và quyền ).

Một trường hợp giả định 3 có thể sai là trên một hệ thống trong đó một quy trình có thể có khả năng thay đổi chủ sở hữu tệp nhưng chỉ khi họ có quyền ghi trên tệp. Mặc dù hơi thực tế, tôi không biết bất kỳ hệ thống nào trong trường hợp này. Sau đó, chgrpđến một nhóm từ một quá trình chạy không phải là root cũng như người dùng sở hữu tệp có thể làm cho tệp bị giới hạn cho một lần sau chown.

Đối với một cuộc gọi đệ quy, có những trường hợp cạnh trong đó toàn bộ đường chuyền được chgrptheo sau bởi toàn bộ đường chuyền chowncó thể thất bại khi một đường chuyền duy nhất sẽ thành công. Đây không phải là một lập luận rất thuyết phục bởi vì nó liên quan đến các thư mục mà chủ sở hữu không có quyền truy cập và một ứng dụng muốn bảo vệ chống lại tất cả các trường hợp như vậy sẽ cần phải sử dụng các quyền. Tuy nhiên, về mặt kỹ thuật nó đáp ứng điều kiện của lý do này. Giả sử rằng quy trình đang chạy có người dùng hiệu quả alice, nhóm hiệu quả staffvà khả năng thay đổi chủ sở hữu tệp một cách tùy tiện (không chỉ cho họ đi; một số biến thể unix có khả năng như vậy, mặc dù hiếm khi được cấp cho các quy trình không root).

$ ls -ld dir dir/file
d---rwx---  2 charlie  staff        1024 Apr  1  1970 dir
drw-rw----  2 charlie  staff          42 Apr  1  1970 file
$ chgrp -R students dir
$ chown -R bob dir
chown: dir: permission denied