Các bit dính ban đầu đã làm gì khi áp dụng cho các tập tin?


65

Ở nhiều nơi khác nhau, người ta có thể thấy "bit dính" bị cáo buộc ngày nay là một từ sai hoàn toàn, vì chức năng của nó hiện nay là ảnh hưởng đến quyền ghi trên các thư mục và hoạt động như một cờ xóa bị hạn chế .

Trong câu trả lời của AskUbfox, người trả lời đã viết rằng "một bit dính thường áp dụng cho các thư mục" . Tôi quan sát thấy rằng các hệ thống hiện đại trong thực tế dường như không bao giờ áp dụng nó cho các tệp, nhưng từ lâu, trường hợp thông thường là để áp dụng cho các tệp (hình ảnh chương trình thực thi) thay vì cho các thư mục. (Khi nói đến việc sử dụng hiện đại trên các tệp, có một câu hỏi liên quan tại Có phải bit dính không được sử dụng trong các hệ thống tệp hiện tại .)

Điều này đặt ra câu hỏi:

Có gì không một chút dính áp dụng cho một thực thi làm gì? Có phải nó giống như setuid không?

Lưu ý thì quá khứ. Đây không phải là làm thế nào để bit dính hoạt động? hiện nay. Đó là cách nó được sử dụng để làm việc sau đó.


3
Tôi muốn chỉ ra rằng "Tôi quan sát thấy rằng thực sự các hệ thống hiện đại dường như không bao giờ áp dụng nó vào các tập tin" chỉ đúng với một số hệ thống. Trang Wikipedia về ghi chú bit dính , "Hiện tại, hành vi này chỉ hoạt động trong HP-UX và UnixWare." Nó có một biểu đồ cho thấy các triển khai khác nhau: luồng chung là các hệ điều hành bỏ qua nó hoặc xử lý nó để xác định cách bộ nhớ / trao đổi / vv. nên được xử lý. Các chi tiết về cách thức được sử dụng khác nhau giữa các hệ điều hành. ví dụ, không có hệ thống Linux nào từng sử dụng bit dính như câu trả lời của JdeBP.
TẤT CẢ NGÀY

Câu trả lời:


91

Không, bit dính không giống như các cờ set-UID hoặc set-GID. Nó không ảnh hưởng đến bất kỳ thay đổi nào trong quá trình xác thực.

Những gì các bit dính đã làm là làm cho văn bản chương trình "dính". Đó không phải là một cách gọi sai, ban đầu.

nền: phần hình ảnh chương trình và văn bản chia sẻ

Về bản chất, không đi sâu vào chi tiết các định dạng tệp thực thi (có thể và có, có đầy sách): Các phần của tệp hình ảnh chương trình được tải trực tiếp vào bộ nhớ để chạy chương trình bao gồm mã máy, hằng, khởi động các giá trị của các biến (không bắt đầu bằng 0) và (ở dạng này hay dạng khác) khoảng trắng cho các biến không khởi tạo và không khởi tạo.

Chúng được nhóm thành các bộ sưu tập được gọi là "phần" và chúng có tên thông thường. Mã máy và (đôi khi) các hằng số tạo thành phần thường được gọi là phần "văn bản" của hình ảnh chương trình. Các biến không khởi tạo khác, tương tự, là phần "dữ liệu"; và các biến không khởi tạo và không khởi tạo là "bss" (một tên mà chính nó có toàn bộ lịch sử dân gian đằng sau nó).

Khi một quá trình có tệp hình ảnh thực thi chương trình được tải vào nó, các phần khác nhau - văn bản, dữ liệu và bss - được khởi tạo từ nội dung của tệp hình ảnh.

Điều đặc biệt ở phần "văn bản" là mã máy (và các hằng số) hầu như không được ghi vào. Nó có khả năng được chia sẻ trên các hình ảnh bộ nhớ ảo của tất cả quá trình thực thi có tệp hình ảnh thực thi đó được tải vào chúng. Kịch bản chính xác trong đó văn bản chương trình có thể được chia sẻ nằm ngoài phạm vi của câu trả lời này và liên quan đến những thứ như tính không ổn định của trình tải và nhận dạng bố cục không gian địa chỉ. Mọi người cũng có thể và đã viết sách về chủ đề này. ☺

Văn bản chia sẻ là một tối ưu hóa được sử dụng bởi kernel. Nó loại bỏ sự cần thiết cho mọi phiên bản của một hình ảnh chương trình đang chạy để có hình ảnh bộ nhớ riêng, tiêu thụ bộ nhớ vật lý quý giá với nhiều bản sao của cùng một mã máy (và hằng số).

văn bản dính

Nhưng người ta có thể làm tốt hơn so với văn bản chia sẻ. Rõ ràng, nếu luôn có ít nhất một tiến trình đang sử dụng một hình ảnh chương trình văn bản được chia sẻ cụ thể, thì kernel chỉ cần gắn không gian bộ nhớ ảo của các tiến trình mới vào phân đoạn văn bản chia sẻ hiện có khi một phiên bản mới của chương trình được chạy. Hầu như luôn luôn có một phiên bản (nói) /bin/loginhoặc /bin/shchạy ở đâu đó trên một hệ thống cỡ trung bình, vì vậy các phiên bản mới của chương trình đăng nhập hoặc trình bao mặc định có thể chỉ cần đính kèm vào các bản sao được tải của các đoạn văn bản mà hạt nhân đã tải vào bộ nhớ.

Văn bản dính mở rộng ý tưởng này để lập trình hình ảnh mà không có quá trình hiện đang chạy . Nếu một tệp hình ảnh thực thi được đánh dấu là văn bản dính, thì hạt nhân sẽ giữ đoạn văn bản của nó xung quanh sau quá trình cuối cùng để sử dụng nó thoát ra; với hy vọng rằng một phiên bản khác của chương trình sẽ sớm được thực thi và chỉ có thể đính kèm lại vào phân khúc.

Trong các Thông báo ban đầu, các phân đoạn văn bản dính đã tải sẽ được hoán đổi để trao đổi lưu trữ khi không có quy trình nào được đính kèm. (Các thông báo sau này đã ngừng sử dụng trao đổi cho việc này.) Bạn cũng có thể đã nghe về điều này bằng tên văn bản đã lưu .

Tất nhiên, thiết lập bit văn bản dính trên hình ảnh chương trình là việc cần phải thực hiện cẩn thận. Những chương trình được hưởng lợi từ nó phụ thuộc vào những gì máy thường được sử dụng cho. Và các phân đoạn văn bản hiện tại không được quản lý chiếm tài nguyên kernel, có nghĩa là có giới hạn thực tế đối với số lượng văn bản có thể có trong bất kỳ hệ thống nào. Vì vậy, nó thường là một hoạt động đòi hỏi đặc quyền siêu người dùng.

desuetude

Có rất nhiều giả định làm cơ sở cho hoạt động của văn bản dính, điều đó không còn đúng nữa. Đọc một phân đoạn được tạo sẵn từ bộ lưu trữ trao đổi không nhất thiết phải nhanh hơn phân trang nhu cầu đơn giản từ tệp hình ảnh thực thi thực tế. Các định dạng hệ thống tập tin trở nên tốt hơn cho các mẫu đọc ngẫu nhiên (trái ngược với tuần tự). Sự xuất hiện của nhu cầu phân trang tự thay đổi mọi thứ, cũng như những thứ như bộ nhớ đệm thống nhất, bản sửa lỗi bên ngoài không phải là kết quả do sự khác biệt trong tìm kiếm thư viện chia sẻ và ngẫu nhiên bố trí không gian địa chỉ.

Ngày của các bit văn bản dính cho hình ảnh chương trình thực thi đã qua lâu rồi. Ví dụ, một cờ đánh dấu văn bản dính rõ ràng cho hình ảnh chương trình thực thi đã bị các nhà văn của 4.3BSD coi là lỗi thời vào giữa những năm 1980.

đọc thêm

  • Maurice J. Bach (1986). Thiết kế của hệ điều hành UNIX . Hội trường-Prentice. SỐ TIẾNG VIỆT 323299992.

1
Câu trả lời rất hay! Hôm nay tôi đã học được điều gì đó. :)
Andreas Wiese

Tôi cũng vậy :) Điều này nghe có vẻ giống như những gì tôi từng biết TSRtrong thời kỳ DOS - "chấm dứt và cư trú". Tuy nhiên, điều đó thường dành cho những thứ như trình điều khiển thiết bị mà các quá trình khác chạy sau này cần phải gọi và có thể đã lỗi thời khi thế giới chuyển sang HĐH đa luồng / đa tiến trình.
Steve

1
Đây là một câu trả lời tuyệt vời. Tôi có thể đọc về nguồn gốc của bssđâu?
mèo

1
TSR không thực sự tương tự. Để biết các sự tương tự trong thế giới IBM + Microsoft, hãy tìm đến DOS + Windows 3.x ở Chế độ tiêu chuẩn và phiên bản OS / 2 16 bit 1.x. Các CODEphân đoạn (và trên DATAcác phân đoạn chỉ đọc trên OS / 2 ) của EXE và DLL được (thường) được chia sẻ giữa tất cả các chương trình đang chạy. Không có sự tương đương thực sự với "độ dính", một phần vì OS 32 bit phiên bản 2.x và 386 Chế độ nâng cao thay thế phân đoạn hoán đổi với bộ nhớ ảo được phân trang theo yêu cầu, giống như thế giới Unix đã có trước đó vài năm, trong cả hai đấu trường đều ảnh hưởng đến cần cho độ dính phân khúc theo nhiều cách giống nhau.
JdeBP

3
@JdeBP: Câu hỏi "Có phải bit dính như setuid không?" là khá rộng và không chính xác. Tôi sẽ lập luận rằng câu trả lời là "Chà, phần nào; nó phức tạp" bởi vì chín bit thứ tự thấp và tương tự nhau: chúng ảnh hưởng đến việc người dùng nhất định có thể thực hiện một số thao tác nhất định trên một tệp hay không. Và các bit set-UID, set-GID và các bit dính tương tự nhau ở chỗ chúng không liên quan đến việc một hoạt động có được phép hay không, mà thay vào đó kiểm duyệt một số khía cạnh về cách thức hoạt động của nó (cụ thể là hoạt động thực thi).
G-Man
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.