D-Bus kimlik doğrulaması ve yetkilendirme

D-Bus'a uzaktan erişim kurmaya çalışıyorum ve kimlik doğrulama ve yetkilendirmenin (çalışmıyor) nasıl çalıştığını anlamıyorum.

Soyut bir soketi dinleyen bir D-Bus sunucum var.

$ echo $DBUS_SESSION_BUS_ADDRESS 
unix:abstract=/tmp/dbus-g5sxxvDlmz,guid=49bd93b893fe40d83604952155190c31

dbus-monitorNeler olup bittiğini izlemek için koşuyorum . Test durumum notify-send hello, yerel makineden yürütüldüğünde çalışan.

Aynı makinedeki başka bir hesaptan, bu veriyoluna bağlanamıyorum.

otheraccount$ DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-g5sxxvDlmz,guid=49bd93b893fe40d83604952155190c31 dbus-monitor
Failed to open connection to session bus: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
otheraccount$ DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-g5sxxvDlmz,guid=49bd93b893fe40d83604952155190c31 notify-send hello

D-Bus spesifikasyonuna göz attıktan sonra ~/.dbus-keyrings/org_freedesktop_general, diğer hesaba kopyaladım , ancak yardımcı olmuyor.

Ben esinlenerek TCP üzerinden D-Bus soketi, yönlendirme çalıştı schedar 'ın Erişim D-Bus uzaktan SoCat kullanarak .

socat TCP-LISTEN:8004,reuseaddr,fork,range=127.0.0.1/32 ABSTRACT-CONNECT:/tmp/dbus-g5sxxvDlmz

TCP soketine hesabımdan bağlanabiliyorum.

DBUS_SESSION_BUS_ADDRESS=tcp:host=127.0.0.1,port=8004 notify-send hello

Ama öteki hesaptan değil, ne ile dbus-monitorne de notify-send. dbus-monitorSoyut soket ile aynı hata mesajı ; notify-sendşimdi bir iz yayıyor:

otheraccount$ DBUS_SESSION_BUS_ADDRESS=tcp:host=127.0.0.1,port=8004 notify-send hello

** (notify-send:2952): WARNING **: The connection is closed

Stracing, bu sürümünün notify-sendçerez dosyasını okumaya çalışmadığını, bu yüzden neden bağlanamayacağını anlıyorum.

Ayrıca SSHing'i başka bir makineye denedim ve TCP bağlantısını yönlendirdim.

ssh -R 8004:localhost:8004 remotehost

Şaşırtıcı bir şekilde, dbus-monitorbir çerez dosyası olmadan çalışır! Uzak ana bilgisayardan D-Bus trafiğini izleyebilirim. Yerel örneğimde gizli dinleme hakkında bir uyarı görüyorum dbus-monitor.

remotehost$ DBUS_SESSION_BUS_ADDRESS=tcp:host=127.0.0.1,port=8004 dbus-monitor
signal sender=org.freedesktop.DBus -> dest=:1.58 serial=2 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameAcquired
   string ":1.58"
method call sender=:1.58 -> dest=org.freedesktop.DBus serial=2 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=AddMatch
   string "eavesdrop=true"

notify-sendYerel makinede çalışırsam dbus-monitor, uzak ana bilgisayarda bildirimi görür. Kesinlikle kimlik doğrulaması gerektiren bir erişim düzeyine ulaştı.

notify-sendbir çerez bulamadığından şikayet etti. Çerez dosyasını kopyaladıktan sonra notify-send, uzak makineden çalışır.

Yerel makine Debian'ı hırıltılı olarak çalıştırıyor. Uzaktaki makine FreeBSD 10.1 çalıştırır.

D-Bus kimlik doğrulamasının ve yetkilendirmesinin nasıl çalıştığını anlamıyorum.

1. Uzak makineden kimlik bilgileri olmadan neden anlatabildiğim kadarıyla kulak misafiri olabilirim? D-Bus'ı bir TCP bağlantısına ilettiğimde ne açığa çıkarıyorum? Yetkilendirmeler neden farklı dbus-monitorve notify-sendfarklı?
2. Soyut soket üzerinden veya TCP bağlantısı üzerinden neden aynı makinedeki başka bir hesaptan dinleyemiyorum?
3. Çerez dosyasının birkaç dakikada bir değiştiğini fark ettim (düzenli aralıklarla olup olmadığını anlayamadım). Neden?

(TCP'yi dinleyen bir D-Bus arka plan programı başlatabileceğimi biliyorum. Sorumun amacı bu değil, neden yaptığımı ve çalışmadığımı anlamak istiyorum.)

D-Bus burada sihirli çerez dosyasını kullanmıyor; kimlik bilgilerini UNIX etki alanı soketi ( SCM_CREDENTIALS) üzerinden geçiriyor .

Sihirli çerez dosyası birkaç D-Bus kimlik doğrulama mekanizmasından sadece biridir. D-Bus , çok çeşitli kimlik doğrulama mekanizmalarını desteklemek için SASL uyumlu bir arayüz (bkz. RFC4422 ) uygular . Bu mekanizmalardan birine "HARİCİ" kimlik doğrulaması denir ve bu, kimlik doğrulamasını garanti etmek için taşıma kanalının kendisinin kullanılması gerektiği anlamına gelir. En azından UNIX soketleri üzerinden D-Bus olması durumunda, bu, denenen ilk kimlik doğrulama mekanizması gibi görünüyor.

D-Bus spesifikasyonundan:

Özel kimlikler geçen boş bayt

Sunucuya bağlandıktan hemen sonra, istemci tek bir boş bayt göndermelidir. Bu bayt, kimlik bilgilerini UNIX etki alanı yuvaları üzerinden geçirmek için SCM_CREDS veya SCM_CREDENTIALS ile sendmsg () kullanan bazı işletim sistemlerinde kimlik bilgileriyle birlikte olabilir. Bununla birlikte, boş bayt, diğer soket türlerinde ve hatta kimlik bilgilerini iletmek için bayt gönderilmesini gerektirmeyen işletim sistemlerinde bile gönderilmelidir. Bu belgede açıklanan metin protokolü, tek nul bayttan sonra başlar. İstemciden alınan ilk bayt boş bir bayt değilse, sunucu bu istemcinin bağlantısını kesebilir.

İlk bayt dışındaki herhangi bir bağlamdaki boş bayt bir hatadır; protokol yalnızca ASCII'dir.

Nul bayt ile birlikte gönderilen kimlik bilgileri, SASL mekanizması EXTERNAL ile kullanılabilir.

Örneğini dbus-daemonbağlarsanız, bağlandığınızda bağlanan kullanıcının kimlik bilgilerini kontrol ettiğini görebilirsiniz:

$ strace dbus-daemon --session --nofork
...
accept4(4, {sa_family=AF_LOCAL, NULL}, [2], SOCK_CLOEXEC) = 8
...
recvmsg(8, {msg_name(0)=NULL, msg_iov(1)=[{"\0", 1}], msg_controllen=0, msg_flags=0}, 0) = 1
getsockopt(8, SOL_SOCKET, SO_PEERCRED, {pid=6694, uid=1000, gid=1000}, [12]) = 0

Sorularınızı cevaplamak için:

1. D-Bus arka plan programı kimliğinizi doğrulamak için çekirdek doğrulamalı kullanıcı kimliğinizi kullanıyor. Kullanarak socatvekil bağlantıları sayesinde, herkes sizin UID kullanarak cin D-Bus bağlanmak izin vardır.

2. Başka bir UID'den doğrudan sokete bağlanmaya çalışırsanız, arka plan programı, bağlanan UID'nin bağlanmasına izin verilmesi gereken bir UID olmadığını tanır. Ben varsayılan varsayılan sadece daemon kendi UID izin olduğunu, ancak resmen bunu doğrulamamıştır inanıyorum. Yine de diğer kullanıcılara izin verebilirsiniz: yapılandırma dosyalarına /etc/dbus-1/ve ayrıca man dbus-daemon.

3. Bu, eski / süresi dolmuş çerezleri yenileriyle değiştiren D-Bus sunucusudur. D-Bus spesifikasyonunun DBUS_COOKIE_SHA1 bölümüne göre , bir çerez oluşturma süresiyle birlikte saklanır ve sunucunun çok eski olduğuna karar verdiği çerezleri silmesi gerekir. Görünüşe göre ömrü "oldukça kısa olabilir".