Viết bên trong một ổ cắm mở bởi một quy trình khác trong Linux

Có thể trên Linux cho một quá trình để viết bên trong một ổ cắm được mở bởi một cái khác?

Giả sử tôi mở kết nối với google.com bằng netcat:

myuser@linux:~$ nc google.com 80

Bây giờ tôi có thể tra cứu quá trình pid và mở thư mục mô tả tập tin của nó:

myuser@linux:~$ ls -la /proc/24105/fd
totale 0
dr-x------ 2 myuser myuser  0 2012-03-10 19:01 .
dr-xr-xr-x 7 myuser myuser  0 2012-03-10 19:01 ..
lrwx------ 1 myuser myuser 64 2012-03-10 19:02 0 -> /dev/pts/12
lrwx------ 1 myuser myuser 64 2012-03-10 19:02 1 -> /dev/pts/12
lrwx------ 1 myuser myuser 64 2012-03-10 19:01 2 -> /dev/pts/12
lrwx------ 1 myuser myuser 64 2012-03-10 19:02 3 -> socket:[3947162]

Vì vậy, bây giờ tôi muốn thực hiện yêu cầu HTTP bằng cách sử dụng tiếng vang bên trong ổ cắm đó:

myuser@linux:~$ echo "GET / HTTP/1.1" >> /proc/24285/fd/3
bash: /proc/24285/fd/3: no such device or address

Làm điều đó như root không thay đổi kết quả.

Tôi không thể viết bên trong ổ cắm nhưng tôi có thể viết bên trong stdin:

myuser@linux:~$ echo "GET / HTTP/1.1" >> /proc/24285/fd/0
myuser@linux:~$

Nhưng đó không phải là điều tôi muốn làm.

Tôi đã suy nghĩ: một ổ cắm Linux nên được coi như một tập tin, phải không? Một hoặc nhiều quy trình có thể sử dụng cùng một ổ cắm, vậy tại sao tôi không thể làm điều này?

Điều này là không thể bởi vì nó sẽ khó thực hiện và hiếm khi hữu ích. Ổ cắm phức tạp hơn nhiều so với đường ống:

• Ổ cắm là hai chiều.
• Có nhiều loại ổ cắm khác nhau. Một số socket không phải là luồng byte (ví dụ, socket UDP là socket datagram, chúng gửi các gói và không phải byte).
• Các socket thực hiện ghép kênh (và có một số quá tải giữa các socket được sử dụng bởi các máy chủ đang chờ kết nối và socket được sử dụng bởi các kết nối mở thực tế).

Bởi vì các socket là hai chiều, chúng thường được sử dụng để giao tiếp theo các giao thức hai chiều. Nếu bạn đưa dữ liệu vào cuộc trò chuyện, phía bên kia có thể gửi phản hồi cho dữ liệu của bạn và không có cách nào để gửi phản hồi cho người yêu cầu đúng. Điều này làm giảm đáng kể tính hữu ích của việc cho phép tiêm dữ liệu vào ổ cắm.

Nếu bạn đang cố gắng liên hệ với cùng một máy chủ với một máy khách hiện tại và không tham gia vào một cuộc trò chuyện hiện có, thì có một cách để làm điều đó: liên hệ với máy chủ theo cách tương tự (mở một ổ cắm trên hệ thống tệp hoặc đến TCP hoặc cổng UDP). Nếu ổ cắm là một cái không tên giữa hai quy trình, thì đó là một gợi ý hay mà bạn không nên tham gia, vì vậy hệ điều hành không làm cho nó dễ dàng.

Với một ổ cắm datagram (không phải trường hợp ở đây), bạn không thể trực tiếp tiêm dữ liệu vì trình bao chỉ hiểu các luồng byte, nó không biết gọi sendthay vì writegửi một gói.

Nếu bạn có sự hợp tác của một điểm cuối, bạn có thể yêu cầu sử dụng mô tả tệp qua 1 2 3 .

Mặt khác, bạn có thể làm cho quá trình mở ổ cắm gửi dữ liệu, với ptrace(đó là những gì gdbsử dụng dưới mui xe). Điều này đình chỉ quá trình, rất nhiều theo thiết kế, để các thủ thuật bẩn của bạn không nhầm lẫn quá trình này quá nhiều. Ngay cả khi quy trình bị treo, bạn vẫn gặp rủi ro lớn là làm cho cấu trúc dữ liệu của quy trình không phù hợp với thực tế của dữ liệu hoặc sửa đổi môi trường mà bạn đã đưa vào. (Lưu ý rằng ngay cả khi hệ thống cho phép tiêm dữ liệu qua ổ cắm, sẽ có một trường hợp tương tự, nếu ít hơn, có nguy cơ nhầm lẫn quy trình với những sự không nhất quán này.)

Tôi muốn nói là có thể, nhưng cả hai quá trình cần hợp tác để làm điều này. Bạn có thể có một quy trình gửi một bộ mô tả tệp qua kết nối ổ cắm đến một quy trình khác. Tôi tìm thấy ví dụ này, có vẻ như hoạt động trên một máy Arch linux cập nhật.