Tại sao setuid bị bỏ qua trên các thư mục?

Trên các hệ thống Linux, bạn có thể thành công chmod u+s $some_directory, nhưng thay vì buộc quyền sở hữu các thư mục con và tệp mới phải là chủ sở hữu của thư mục chứa ( u+scũng như đặt các thư mục con ) như bạn mong đợi, hệ thống chỉ bỏ qua bit setuid. Các thư mục con và tệp tiếp tục kế thừa UID của các quy trình tạo của chúng và các thư mục con không được đặt theo mặc định.

Tại sao setuid bị bỏ qua trên các thư mục và làm cách nào để hệ thống nhận ra nó?

Hãy nhớ lại rằng các bit setuid và setgid được phát minh cho một mục đích hoàn toàn khác: khiến cho một tệp thực thi chạy với uid hoặc gid của chủ sở hữu, thay vì uid hoặc gid của người dùng đang chạy tệp. Bất kỳ việc sử dụng khác chỉ là một tính năng bổ sung.

Các bit này không có chức năng trên các tệp thông thường không thể thực thi được. (Và cả shell script trên một số distro, do vấn đề bảo mật.) Ban đầu, chúng cũng không có chức năng cho các thư mục. Rõ ràng là ai đó đã quyết định sẽ rất tuyệt khi lấy setgid không sử dụng trên các thư mục và sử dụng nó để thực thi tính nhất quán của quyền sở hữu nhóm. Xét cho cùng, nếu bạn đang chơi với quyền sở hữu nhóm, thì đó là vì có nhiều hơn một người đang làm việc với tệp và có thể có ý nghĩa cho tất cả các tệp trong một thư mục nhất định thuộc về cùng một nhóm, bất kể ai đã tạo ra chúng. Sự lộn xộn do ai đó quên chạy newgrp được loại bỏ.

Vì vậy, tại sao không thực hiện tính năng tương tự cho setuid và tệp uid? Chà, uid cơ bản hơn nhiều so với gid. Nếu bạn thực hiện điều này, thường thì một tệp sẽ không thuộc về người dùng đã tạo ra nó! Có lẽ người dùng vẫn có thể sửa đổi tệp (giả sử umask là thứ gì đó lành mạnh), nhưng họ không thể thay đổi các bit cho phép. Khó thấy tiện ích đó.

Tôi tin rằng câu trả lời cho câu hỏi này liên quan đến các vấn đề bảo mật "giveaway tập tin" đã dẫn đến hầu hết các hệ điều hành giống như Unix hiện đại không cho phép "tặng cho tập tin". "Giveaway tệp" là khi người dùng không phải là siêu người dùng thay đổi quyền sở hữu tệp đối với người khác không phải người dùng đó. Khả năng này cung cấp nhiều cơ hội cho sự tinh nghịch.

Vì quà tặng tập tin không được phép, setuid trên các thư mục, sẽ thực hiện cùng chức năng ở dạng khác, không được phép hoặc bị bỏ qua nếu được đặt.

Để thay đổi hành vi, bạn sẽ phải sửa đổi các thư viện và tiện ích hệ điều hành.

Một trường hợp sử dụng rất tốt để thực hiện nó là:

Hãy nói rằng bạn có một máy chủ nhiều trang web với 3 trang web an toàn. Bạn có 3 nhóm được tạo, một nhóm cho mỗi người duy trì trang web khác nhau. Tất cả các tệp trong tất cả các trang web cần phải được sở hữu bởi người dùng apache để apache có thể đọc và ghi cho chúng (drupal / wordpress, v.v.).

Nếu setuid nhưng hoạt động như bit setgid cho các quyền của thư mục sẽ trông giống như thế này:

/var/www/sitea - apache:groupa  rwS rwS ---
/var/www/siteb - apache:groupb  rwS rwS ---
/var/www/sitec - apache:groupc  rwS rwS ---

Bằng cách này, mỗi nhóm người bảo trì có quyền truy cập để xem và chỉ chạm vào nội dung của họ nhưng apache người dùng máy chủ web có thể phục vụ tất cả nội dung và người dùng không cần phải lo lắng về việc thay đổi quyền sở hữu các tệp được tải lên.

Một trường hợp sử dụng khác là cho tải lên ẩn danh ftp / http hoặc thậm chí sftp / ssh. Nhóm và GID trên thư mục tải lên sẽ là root và chủ sở hữu và UID cũng vậy. Các quyền khác sẽ là -wx. Điều này sẽ cho phép mọi người VIẾT truy cập vào thư mục tải lên nhưng họ không thể đọc bất cứ điều gì một khi nó được tải lên và root sẽ sở hữu tất cả các tệp mới được tạo.

Vì vậy, có hai trường hợp sử dụng hoàn toàn tốt và hợp lệ để cho phép chức năng UID trên các thư mục khớp với bit GID.

Steven Mercurio

Đến bữa tiệc muộn một chút, nhưng trong trường hợp độc giả tương lai vấp phải điều này;) Như đã nói bởi những người khác, trên hệ thống tệp OS-X tiêu chuẩn, setUID cho các thư mục bị bỏ qua - và dường như không có cách nào dễ dàng để giải quyết vấn đề này ( mount -o.... hoặc những gì không). Như thường lệ, trang man thực sự không tuân thủ hành vi OS-X mà nó nói theo nghĩa đen:

4000 (bit thực thi ID người dùng tập hợp) [...] Các thư mục với tập bit-set-user-id sẽ buộc tất cả các tệp và thư mục con được tạo trong chúng phải thuộc sở hữu của chủ sở hữu thư mục chứ không phải bởi chủ sở hữu thư mục uid của quá trình tạo [...]

nhưng nó cũng liệt kê một khả năng để đạt được hiệu quả tương tự mà không từ bỏ quyền sở hữu ban đầu. Linux sử dụng '[g /] setfacls' cho các hiệu ứng tương tự (các quyền này không thực sự hiển thị ngay từ cái nhìn đầu tiên, do đó đôi khi có thể gây phiền toái).

Về phần 'làm thế nào tôi có thể đạt được các hiệu ứng tương tự', hãy đọc toàn bộ trang man và mân mê với:

chmod +a 'guest allow read,write,delete,add_file,add_subdirectory,file_inherit,directory_inherit' ./[DIRECTORY]

bạn có thể kiểm tra thông qua

ls -le

nếu tất cả đều ổn Các tùy chọn khác bao gồm chèn quy tắc tại các vị trí cụ thể, loại bỏ hoặc thay thế quy tắc cụ thể. Hai tùy chọn đáng chú ý ở đây là " file_inheritvà directory_inherit" cho phép các quy tắc được đính kèm vào một thư mục / tệp mới.

Tôi không thực sự thích sử dụng setUID, nhưng setGID rất tiện dụng trên các trình lưu trữ tệp, nơi chỉ đơn giản là đặt nhóm 'chính' không hoạt động hoặc khách hàng có các tệp filem không cho phép ghi nhóm. Điều đó sẽ được giải quyết bằng cách:

chmod +a 'mygroup allow read,write,delete,add_file,add_subdirectory,file_inherit,directory_inherit' /fileserver/groupfolders/mygroup

Vâng, nó nên tôn trọng các tiêu chuẩn. Tôi có thể nghĩ về một vài bối cảnh chỉ với sftp rằng nó sẽ giúp tôi tiết kiệm rất nhiều rắc rối, cả với acl và acl-mask-set mà sshd làm, và thiết lập lại mà tôi phải làm với mặt nạ đó.

Bảo mật theo mặc định là khá hữu ích, nhưng nếu bạn không biến nó thành một tùy chọn, bạn chỉ đang tạo ra một cú hích.

https://www.gnu.org/software/coreutils/manual/html_node/Directory-setuid-and-setgid.html

Dù bằng cách nào, nó cũng giống như Linux hiện nay, vì vậy chỉ cần sử dụng acl để xử lý chúng.

Theo http://en.wikipedia.org/wiki/setuid#setuid_and_setgid_on_directories , bit setuid bị bỏ qua cho các thư mục trên cả hai hệ thống UNIX và Linux. Tuy nhiên, có thể làm cho nó hoạt động như bạn mong đợi trên FreeBSD.