Cho phép nhóm không sudo kiểm soát công việc mới bắt đầu


11

Tôi đang cố gắng thiết lập một công việc Upstart để chạy khi khởi động hệ thống và điều đó cũng có thể được bắt đầu / dừng bởi các thành viên của một nhóm khác sudo. Với phiên bản trước, tôi đã sử dụng update-rc.dvà các tập lệnh được lưu trữ /etc/init.d/để hoạt động này bằng cách thêm %Group ALL = NOPASSWD: /etc/init.d/scriptnamevào tệp sudoers của tôi, nhưng dường như tôi không thể có được một hoạt động tương đương cho Upstart.

Tôi đã thử thêm %Group ALL = NOPASSWD: /sbin/initctl start jobnamevào tập tin sudoers, nhưng cố gắng chạy lệnh start jobnametạo ra lỗi này:

start: Rejected send message, 1 matched rules; type="method_call", sender=":1.21" (uid=1000 pid=5148 comm="start jobname " interface="com.ubuntu.Upstart0_6.Job" member="Start" error name="(unset)" requested_reply="0" destination="com.ubuntu.Upstart" (uid=0 pid=1 comm="/sbin/init")

Gần như tôi có thể nói, đó là một khiếu nại về cách tài khoản người dùng của tôi không được cung cấp sức mạnh để gửi tin nhắn 'Bắt ​​đầu' trong tệp cấu hình D-Bus cho Upstart. Tôi thực sự không thể tìm thấy bất kỳ thông tin nào về cách chỉnh sửa tệp đó để cấp quyền cho nhóm truy cập một dịch vụ cụ thể - có tồn tại tùy chọn như vậy không? Có cách nào để chỉnh sửa tệp Sudoers để tôi có thể chạy công việc mà không cần chỉnh sửa tệp cấu hình không? Tôi có tốt hơn khi chỉ gắn bó với phiên bản trước?

Câu trả lời:


7

Bạn có thể bắt đầu với việc tìm ra nơi giữ cấu hình D-Bus cụ thể cho Upstart. Xem destination="com.ubuntu.Upstart"đoạn trích đó từ thông báo lỗi? Bây giờ hãy thử grep nó trong thư mục với các tệp cấu hình D-Bus:

vhost07:~ $ grep -r "com.ubuntu.Upstart" /etc/dbus-1
/etc/dbus-1/system.d/Upstart.conf:    <allow own="com.ubuntu.Upstart" />
[...skipped...]

Upstart.confTập tin đó có một số ví dụ về chính sách. Tôi đoán bạn có thể cố gắng tìm ra định dạng của một chính sách từ họ. Sau đó cố gắng cho phép người dùng cụ thể của bạn chỉ những hành động mà nó cần. Ví dụ, như trong:

<policy user="pope_benedict">
  <allow send_destination="com.ubuntu.Upstart"
         send_interface="com.ubuntu.Upstart0_6.Job"
         send_member="Start"/>
</policy>

Điều này sẽ cho phép pope_benedictngười dùng bắt đầu công việc đó.

Lưu ý rằng các giá trị cho các thuộc tính chính sách 'cho phép' được liệt kê trong thông báo lỗi ban đầu của bạn.


1
Ồ, và đừng quên khởi động lại D-Bus sau này! :)
Iuliu Pascaru

Tôi thấy điều này hơi hoang mang, nhưng điều này đã giúp: blog.arkency.com/2014/07/ Khăn
Mike Campbell

7

Cá nhân tôi đang sử dụng dòng sau trong tệp /etc/sudoers.d/jobname_myuser:

myuser ALL = (root) NOPASSWD: /sbin/start jobname, /sbin/stop jobname, /sbin/restart jobname, /sbin/status jobname

như được mô tả ở đây: /server//a/390723/68608


2

Tùy chọn như vậy không tồn tại trong sudo.

Sự khác biệt giữa tập lệnh Sysv và tập tin cấu hình Upstart chỉ là: tập lệnh Sysv là tập lệnh, tập tin thực thi theo cách riêng của chúng và bạn có thể nói với sudo để cho phép một số nhóm thực thi chúng. Mặt khác, các tệp cấu hình khởi động chỉ đơn thuần là các tệp cấu hình, không phải là các tệp thực thi, vì vậy việc thực thi start(symlink đến initctl) là điều sudo cho phép. Vấn đề của bạn ở đây là cho phép mọi người chạy initctlbạn cho phép họ làm initctlmọi thứ.

Giải pháp là đơn giản nếu mối quan tâm của bạn chỉ trong một công việc duy nhất. Tạo một kịch bản, nói /usr/bin/jobname.shvới

#!/bin/sh
initctl $1 jobname

sau đó chmod 755 /usr/bin/jobname.shvà cuối cùng thêm tệp thực thi đó vào tệp sudoers của bạn:

%Group ALL = NOPASSWD: /usr/bin/jobname.sh

Bằng cách này, mọi người đều có thể gọi jobname.sh starthoặc jobname.sh stopđể kiểm soát công việc cụ thể này. Bạn có thể muốn thêm một số kiểm tra để chỉ cho phép startstoptham số, v.v.


Nói cách khác, vấn đề của tôi không phải là hệ thống từ chối khả năng chạy của các thành viên trong nhóm initctl, mà Upstart từ chối mọi tín hiệu được gửi bởi người dùng / nhóm không được cung cấp một mục chính sách Cho phép trong Upstart.conf? Và không có cách nào để cung cấp bất kỳ mức độ chi tiết nào hơn cài đặt tất cả các công việc hoặc không có trong tệp cấu hình?
Góc O'Saxon

Ban đầu trong trường hợp của bạn đang chạy tốt ngay cả khi không có thay đổi sudoers, Upstart chỉ từ chối các tin nhắn từ nó nếu bạn không cho phép cụ thể nó cho người dùng không root. Xem hai câu trả lời khác. Bạn có thể xác định chính sách dbus trên cơ sở mỗi công việc (xem com.ubuntu.Upstart0_6.<JOB>phần) trong Upstart.conf. Tùy thuộc vào nhu cầu của bạn, có thể đơn giản hơn để tạo loại kịch bản này cho nó thay vì viết chính sách dbus và khởi động lại dbus, v.v ... Chính sách Dbus rõ ràng là điều "đúng", nhưng tùy trường hợp, kịch bản đơn giản có thể đi con đường dài với ít rắc rối.
Tuminoid

Chỉnh sửa chính sách DBus để sử dụng com.ubuntu.Upstart0_6.jobnamenhư send_interfacethông báo lỗi được tạo như trước. Nếu tôi đoán đúng rằng đầu ra lỗi chứa thông tin tín hiệu, giao diện hoặc đích sẽ không phản ánh dịch vụ Khởi động mà tín hiệu đề cập đến. Tôi nghĩ rằng thông tin dịch vụ chỉ là đối số trong thông báo cuộc gọi phương thức D-Bus và tôi không chắc mình có thể chỉnh sửa chính sách D-Bus cho Upstart để đưa ra quyết định dựa trên giá trị đối số.
Góc O'Saxon

Một kịch bản thuộc loại bạn đề xuất đang hoạt động khá tốt đối với tôi, với một cảnh báo: Tôi đã cần chạy nó như sudo jobname.sh startvậy, để Upstart thấy yêu cầu đến từ người dùng. rootTôi đang cố gắng thực hiện đây là cách "đúng" (do đó, di chuyển khỏi tập lệnh Sys-V ở vị trí đầu tiên), vì vậy tôi muốn làm việc này thông qua chính sách D-Bus hoặc một số tùy chọn cấu hình Upstart khác, nhưng nếu tôi không thể làm việc đó tôi sẽ chấp nhận câu trả lời này
Góc O'Saxon

1
Tôi cũng xin trích dẫn "$1". Với [ "$1" = "start" -o "$1" = "stop" ]thử nghiệm của bạn, tôi tin rằng $1việc mở rộng an toàn nhưng không được trích dẫn trong tập lệnh chạy vì root chỉ là thói quen không lành mạnh (trừ khi việc chia tách từ được cố tình mong muốn) ...
Beni Cherniavsky-Paskin

0

Như được chỉ ra ở trên dbus daemon có một tệp cấu hình chuyên về nó cho một ứng dụng cụ thể.

ls /etc/dbus-1/system.d/
avahi-dbus.conf
bluetooth.conf
...
Upstart.conf
wpa_supplicant.con

Tệp cấu hình cũng thiết lập giới hạn tài nguyên, tham số bảo mật, v.v.

Để biết chi tiết, xem dbus-daemon-1 (1) - Trang người dùng Linux

Để cho phép một nhóm bắt đầu / dừng các công việc mới bắt đầu, hãy thêm chính sách sau vào /etc/dbus-1/system.d/Upstart.conf

  <policy group="YourGroupName">
    <allow send_destination="com.ubuntu.Upstart"
       send_interface="com.ubuntu.Upstart0_6.Job"
       send_type="method_call" send_member="Start" />
    <allow send_destination="com.ubuntu.Upstart"
       send_interface="com.ubuntu.Upstart0_6.Job"
       send_type="method_call" send_member="Stop" />
  </policy>

Bạn nên xem xét ý nghĩa bảo mật của chính sách đó trước khi thay đổi chính sách mặc định. Thành viên của YourgroupName sẽ có thể bắt đầu / dừng tất cả các công việc Upstart.


Nhưng có cách nào để hạn chế công việc họ có thể kiểm soát? Hoặc điều đó là không thể vì D-Bus không chú ý đến nội dung tin nhắn?
Góc O'Saxon

Tôi đã thử thêm chính sách đó vào Upstart.conf (thay thế tên nhóm bằng tên nhóm thực tế của tôi), khởi động lại D-Bus và nhận được start: You do not have permission to modify job: jobnamekhi tôi cố gắng khởi động dịch vụ.
Góc O'Saxon

ĐỒNG Ý. Điều đó có nghĩa là chính sách được áp dụng thành công. Dường như yourjob.conf nằm trong / etc / init. Công việc của người dùng nên ở ~ / .init. Có hợp lý trong trường hợp sử dụng của bạn để đặt yourjob.conf trong ~ / .init không?
Goran Miskovic

Liên quan đến câu hỏi đầu tiên của bạn: Chính sách xác định giao diện và thành viên nào có thể được truy cập. Nó không xác định nội dung / đối số nào có thể được gửi / thông qua. Chính sách hạn chế hiện tại đã được nới lỏng xuống thượng nguồn. See không thể bắt đầu để chạy công việc người dùng
Goran Miskovic
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.