Làm thế nào để giết một tiến trình bắt đầu với một người dùng khác mà không cần root hoặc sudoer?


20

trong môi trường Linux, tôi cần phải giết một tiến trình đã được bắt đầu bởi user2 nếu tôi là user1 mà không bị sudo hoặc sử dụng root. Bạn có biết nếu có một cách thiết lập khi khởi chạy quy trình không? Chẳng hạn như một danh sách người dùng được phép giết quá trình?

Thực tế là các phiên bản đồng thời của cùng một quy trình có thể được bắt đầu từ những người dùng khác nhau, đó là lý do tại sao tôi không thuận tiện để đặt id nhóm cho quy trình. Những người dùng khác không thuộc nhóm sẽ không thể bắt đầu quy trình song song thứ hai.

Những gì tôi có là một danh sách người dùng được phép bắt đầu quá trình, được xác định trong cơ sở dữ liệu, trước khi bắt đầu quá trình tôi kiểm tra xem người dùng hiện tại trong danh sách và, nếu có, tôi bắt đầu quá trình với người dùng hiện tại. Nếu một người dùng thứ hai được phép làm điều đó muốn giết quá trình tôi muốn nó được phép làm điều đó nhưng tôi không muốn nó là sudoers.

Do đó, tôi đã suy nghĩ để tạo ra một quy trình chạy bằng root, nhận được yêu cầu tiêu diệt các tiến trình từ người dùng, kiểm tra xem người dùng có được phép bắt đầu / dừng quá trình và giết tiến trình không.

Bạn có nghĩ rằng nó có thể là giải pháp tốt nhất?


Chào mừng đến với SO. Tôi không nghĩ điều này là có thể ... Dù sao, điều này phù hợp hơn với trang web chị em của SO, serverfault.com. Nó có thể được di cư đến đó sớm, không cần phải làm gì cả.
Pekka hỗ trợ GoFundMonica

Chúng ta đang nói về loại chương trình nào? Nó sẽ là khó khăn trong trường hợp chung, nhưng trong một số trường hợp (chẳng hạn như apache hoặc một ứng dụng mà bạn có thể tự sửa đổi) thì sẽ dễ dàng hơn.
Kim

Câu trả lời:


14

Tôi xin lỗi, nhưng điều này đơn giản là không thể (đó là do thiết kế). Tuy nhiên, nếu các thành viên của một nhóm chung, user1 có thể ghi vào một tệp mà tiến trình của user2 kiểm tra, cho biết quá trình mà nó sẽ chấm dứt.

Hoặc, user2 có thể chạy một cái gì đó trong nền kiểm tra một tệp, sau đó gửi các tín hiệu thích hợp. User1 sau đó chỉ cần ghi vào tập tin đó. Điều này có thể dễ dàng hơn, vì nó sẽ không yêu cầu bất kỳ sửa đổi chương trình của user2.

Thông thường, không, user1 không thể gửi tín hiệu POSIX đến quy trình của user2.


Cảm ơn câu trả lời của bạn. Trong trường hợp của tôi, thực sự, tôi không sử dụng tệp nhưng chúng tôi sử dụng một hệ thống ( dim.web.cern.ch/dim ) có thể gửi tín hiệu thích hợp, sau đó một quy trình có thể được gọi là kiểm tra xem người dùng có được phép không dừng quá trình và giết chết quá trình.

@ATeleca - Tôi sử dụng một cái gì đó rất giống nhau để cho phép người dùng kém may mắn kiểm soát / khởi động / dừng các máy ảo Xen trên một trang trại khá lớn. Về cơ bản, điều tương tự.
Tim Post

9

Trừ khi ACL hoặc SELinux hoặc thứ gì khác có cách tốt hơn để làm điều đó, cách tôi đã thấy điều này được thực hiện là với tập lệnh SetUID . Như bạn có thể tưởng tượng, họ nổi tiếng là những rủi ro bảo mật.

Về trường hợp của bạn, giả sử rằng ProcOwner là tên người dùng cho chủ sở hữu quy trình và userA (uid 1000), userB (uid 1201) và userC (uid 1450) là những người được phép giết quá trình.

killmyproc.bash:

#!/bin/bash
case ${UID} in
1000|1201|1450) ;;
*) echo "You are not allowed to kill the process."
   exit 1;;
esac

kill ${PROCESS_ID}
# PROCESS_ID could also be stored somewhere in /var/run.

Sau đó, đặt chủ sở hữu và quyền với:

chown procOwner:procGroup killmyproc.bash
chmod 6750 killmyproc.bash

Và cũng đặt userA, userB và userC trong nhóm procGroup.


Tôi đã thử điều này, và nó đã không hoạt động. Người dùng không phải là chủ sở hữu đã nhận được sự cho phép từ chối lệnh kill.
Javid Jamae

1
Tôi chỉ muốn thêm, tại sao không để hệ thống kiểm soát quyền đối với tập lệnh kill? Tạo một nhóm từ userA, userB và userC, sau đó chọn killscript cho nhóm đó và điều chỉnh nó thành g + x có vẻ gọn gàng hơn đối với tôi.
Leonid Shevtsov

1
bit setUid không được phép trong các kịch bản shell, bạn cần phải tạo chương trình biên dịch trình biên dịch đơn giản để chạy nó
El '

2

Không theo quy ước - có bất kỳ người dùng nào đến và giết chết các quy trình của người khác là lỗ hổng từ chối dịch vụ cuối cùng.

Nó có thể được thực hiện nếu quá trình mục tiêu hợp tác. Một cách là để nó theo dõi sự kiện bên ngoài (như tệp được tạo trong / var / tmp hoặc tin nhắn trên ổ cắm), hướng dẫn nó tự giết mình. Nếu bạn không thể viết nó để làm điều đó, bạn có thể viết một trình bao bọc cho nó để khởi động nó và sau đó thực hiện giám sát, giết chết tiến trình con nếu sự kiện xảy ra.


1

Không, bạn không thể.

Nếu bạn muốn chia sẻ các quy trình với người dùng khác, bạn nên bắt đầu quy trình theo id người dùng chung.


1

Tất nhiên, bạn có thể viết chương trình theo cách nó kết thúc một cách duyên dáng khi nhận được một tín hiệu nhất định (thuật ngữ được sử dụng một cách lỏng lẻo có nghĩa là "sự kiện được xác định trước", không phải là tín hiệu POSIX) từ một người dùng (danh sách) nhất định.


Tín hiệu không có trường "người dùng". Chúng chỉ là tín hiệu.
LtWorf

Đó là lý do tại sao tôi nói "một sự kiện được xác định trước, không phải là tín hiệu POSIX".
drxzcl

1

Bạn có thể viết một chương trình tuyệt vời mà chỉ người dùng trong một nhóm nhất định mới có thể thực thi và sẽ gửi tín hiệu phù hợp đến quy trình. Mặc dù vậy, không chắc chắn bạn muốn loại trừ suid.


0

bit suid không hoạt động với các tập lệnh bash. imho, cách tốt nhất là viết một số tập lệnh bao bọc "killservice". Giả sử, dịch vụ của bạn đang chạy với tư cách là người sử dụng dịch vụ

#!/bin/bash
sudo -u serviceuser /usr/bin/killserviceworker

sau đó

# addgroup servicekiller
# chown root:servicekiller /usr/bin/killservice
# chmod 750 /usr/bin/killservice
# adduser bob servicekiller

sau đó, bạn chỉ cần thêm quy tắc trong / etc / sudoers để cho phép họ chạy / usr / bin / killserviceworker với tư cách là người sử dụng dịch vụ người dùng mà không cần hỏi mật khẩu:

servicekiller        ALL = (serviceuser:serviceuser) NOPASSWD: /usr/bin/killserviceworker

killserviceworker có thể trông như thế này:

#!/bin/bash
kill ${cat /run/service.pid}
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.