Sudo olmayan grubun Upstart işini denetlemesine izin ver


11

Sistem başlangıcında çalıştırmak için bir Upstart işi kurmaya çalışıyorum ve bu da başka bir grubun üyeleri tarafından başlatılabilir / durdurulabilir sudo. Önceki bir sürümde, sudoers dosyasına ekleyerek bu çalışmayı elde etmek için kullandım update-rc.dve komut dosyaları sakladım, ancak Upstart için eşdeğer bir çalışma elde edemiyorum./etc/init.d/%Group ALL = NOPASSWD: /etc/init.d/scriptname

%Group ALL = NOPASSWD: /sbin/initctl start jobnameSudoers dosyasına eklemeyi denedim , ancak komutu çalıştırmaya çalışırken start jobnamebu hatayı veriyor :

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")

Anlayabildiğim kadarıyla, bu, kullanıcı hesabımın Upstart için D-Bus yapılandırma dosyasında 'Başlat' mesajları gönderme gücüne nasıl sahip olmadığına dair bir şikayet. Bir grubun belirli bir hizmete erişim izni vermek için bu dosyayı nasıl düzenleyeceğime dair hiçbir bilgi bulamadım - böyle bir seçenek var mı? Yapılandırma dosyasını düzenlemeden işi çalıştırabilmem için Sudoers dosyasını düzenlemenin bir yolu var mı? Önceki versiyona sadık kalsam daha iyi olur mu?

Yanıtlar:


7

Upstart'a özgü D-Bus yapılandırmasının nerede tutulduğunu öğrenerek başlayabilirsiniz. Bu destination="com.ubuntu.Upstart"snippet'i hata mesajından gördünüz mü? Şimdi D-Bus yapılandırma dosyalarıyla klasörde grep'i deneyin:

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

Bu Upstart.confdosyanın bazı politika örnekleri var. Sanırım onlardan bir politikanın biçimini anlamaya çalışabilirsin. Ardından, belirli kullanıcılarınıza yalnızca ihtiyaç duyduğu eylemlere izin vermeye çalışın. Örneğin, aşağıdaki gibi:

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

Bu, pope_benedictkullanıcının bu işi başlatmasına izin vermelidir .

'İzin ver' ilke özelliklerinin değerlerinin orijinal hata iletinizde listelendiğini unutmayın.


1
Oh, ve bundan sonra D-Bus'u yeniden başlatmayı unutma! :)
Iuliu Pascaru

Bunu biraz şaşırtıcı buldum, ancak bu yardımcı oldu: blog.arkency.com/2014/07/…
Mike Campbell

7

Şahsen /etc/sudoers.d/jobname_myuser dosyasında aşağıdaki satırı kullanıyorum:

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

burada açıklandığı gibi: https://serverfault.com/a/390723/68608


2

Bu seçenek sudo'da mevcut değildir.

Sysv komut dosyaları ve Upstart yapılandırma dosyaları arasındaki fark şudur: Sysv komut dosyaları komut dosyalarıdır, kendi başlarına çalıştırılabilir ve sudo'ya bazı grupların bunları yürütmesine izin vermesini söyleyebilirsiniz. Öte yandan, Upstart yapılandırma dosyaları sadece yürütülebilir dosyalar değil, sadece yapılandırma dosyalarıdır, bu nedenle start(symlink to initctl) yürütülmesi sudo'nun izin verdiği şeydir. Buradaki sorununuz, insanların initctlsizi çalıştırmasına izin vermek, onlara initctlher şeye izin vermektir .

Endişeniz sadece tek bir işte çözüm ise basittir. Bir komut dosyası olun, demek /usr/bin/jobname.shile

#!/bin/sh
initctl $1 jobname

Daha sonra chmod 755 /usr/bin/jobname.shve nihayet sudoers dosyası için bu yürütülebilir ekleyin:

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

Bu şekilde, herkes bu özel işi arayabilir jobname.sh startveya jobname.sh stopkontrol edebilir . Yalnızca izin vermek startve stopparametreler vb. İçin bazı denetimler eklemek isteyebilirsiniz .


Başka bir deyişle, benim sorunum, sistemin grup üyelerini çalıştırma yeteneğini initctlreddetmesi değil, Upstart'ın Upstart.conf'da açıkça bir İlke girdisine izin verilmeyen kullanıcılar / gruplar tarafından gönderilen sinyalleri reddetmesi değil mi? Ve yapılandırma dosyasındaki bir all-jobs-or-none ayarından daha fazla ayrıntı sağlamanın bir yolu yok mu?
Açı O'Saxon

Durumunuzda initctl, sudoers değişmeden bile iyi çalışıyor, Upstart, kök olmayan kullanıcılar için özellikle izin vermezseniz, ondan gelen iletileri reddediyor. Diğer iki cevaba bakınız. com.ubuntu.Upstart0_6.<JOB>Upstart.conf'da dbus politikasını iş başı bazında tanımlayabilirsiniz (bölüme bakın ). İhtiyaçlarınıza bağlı olarak, dbus ilkeleri yazmak ve dbus vb. Yeniden başlatmak yerine bu tür bir komut dosyası yapmak daha basit olabilir. daha az sorunla uzun bir yol.
Tüminoid

DBus politikanın düzenlenmesi kullanmak com.ubuntu.Upstart0_6.jobnameolarak send_interfaceöncekiyle aynı hata mesajı üretti. Hata çıkışının sinyal bilgilerini içerdiğini tahmin etmede haklıysam, arayüzün veya hedefin, sinyalin başvurduğu Upstart hizmetini yansıtmadığını görünüyor. Hizmet bilgilerinin sadece D-Bus yöntemi çağrı iletisinde bağımsız değişkenler olduğunu düşünüyorum ve Upstart için D-Bus ilkesini bağımsız değişken değerlerine dayalı kararlar vermek üzere düzenleyebileceğimden emin değilim.
Açı O'Saxon

Önerdiğiniz türden bir senaryo benim için oldukça iyi çalışıyor, bir uyarı ile: Çalıştırmam gerekiyordu sudo jobname.sh start, böylece Upstart isteği kullanıcıdan gelen olarak görüyor. rootBu "doğru" yol (bu nedenle ilk etapta Sys-V komut dosyalarından uzaklaşın), bu yüzden bu çalışmayı bir D-Bus politikası veya başka bir Upstart yapılandırma seçeneği ile almak istiyorum, ancak yapamıyorsam o işi al bu cevabı kabul edeceğim.
Açı O'Saxon

1
Ben de alıntı yapardım "$1". Senin ile [ "$1" = "start" -o "$1" = "stop" ]testin onun 'için güvenli ama tırnaksız inanmak $1kök olarak bir komut dosyası vadede genişleme sadece sağlıksız alışkanlık (kelime bölme kasten istenen sürece) ve ...
Beni Cherniavsky-Paskin

0

Yukarıda işaret edildiği gibi dbus arka plan programı, belirli bir uygulama için uzmanlaşmış bir yapılandırma dosyasına sahiptir.

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

Yapılandırma dosyası ayrıca kaynak sınırları, güvenlik parametreleri vb. Belirler.

Ayrıntılar için bkz. Dbus-daemon-1 (1) - Linux man sayfası

Bir grubun Upstart işlerini başlatmasına / durdurmasına izin vermek için /etc/dbus-1/system.d/Upstart.conf dosyasına aşağıdaki ilkeyi ekleyin

  <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>

Varsayılan ilkeyi değiştirmeden önce bu tür bir politikanın güvenlikle ilgili sonuçlarını göz önünde bulundurmalısınız. GrupAdınızın üyeleri tüm Upstart işlerini başlatabilir / durdurabilir .


Ancak kontrol edebilecekleri işleri sınırlamanın bir yolu var mı? Yoksa D-Bus mesaj içeriğine dikkat etmediği için bu mümkün değil mi?
Açı O'Saxon

Bu politikayı Upstart.conf'a eklemeyi denedim (grup adını gerçek grup adımla değiştirerek), D-Bus'ı yeniden start: You do not have permission to modify job: jobnamebaşlattım ve hizmeti başlatmaya çalıştığımda aldım .
Açı O'Saxon

TAMAM. Bu, politikanın başarıyla uygulandığı anlamına gelir. Yourjob.conf / etc / init dizininde görünüyor. Kullanıcı işleri ~ / .init içinde olmalıdır. Kullanım durumunuzda yourjob.conf dosyasını ~ / .init içine yerleştirmek akla yatkın mı?
Goran Miskovic

İlk sorunuzla ilgili olarak: Politika, hangi arayüzlere ve üyelere erişilebileceğini tanımlar. Hangi içeriğin / bağımsız değişkenlerin gönderilebileceğini / iletilebileceğini tanımlar. Mevcut kısıtlayıcı politika aşağı yönde kolaylaştırılmıştır. Bkz çalıştırma kullanıcı işi sonradan görme alamayan
Goran Miskoviç
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.