J'essaie de configurer l'accès à distance à D-Bus, et je ne comprends pas comment l'authentification et l'autorisation fonctionnent (pas).
J'ai un serveur D-Bus qui écoute sur une prise abstraite.
$ echo $DBUS_SESSION_BUS_ADDRESS
unix:abstract=/tmp/dbus-g5sxxvDlmz,guid=49bd93b893fe40d83604952155190c31
Je cours dbus-monitor
pour regarder ce qui se passe. Mon cas de test est notify-send hello
, qui fonctionne lorsqu'il est exécuté à partir de la machine locale.
Depuis un autre compte sur la même machine, je ne peux pas me connecter à ce bus.
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
Après avoir parcouru la spécification D-Bus , j'ai copié ~/.dbus-keyrings/org_freedesktop_general
sur l'autre compte, mais cela n'aide pas.
J'ai essayé de transmettre le socket D-Bus sur TCP, en m'inspirant de l' accès D-Bus du planificateur à distance à l'aide de socat .
socat TCP-LISTEN:8004,reuseaddr,fork,range=127.0.0.1/32 ABSTRACT-CONNECT:/tmp/dbus-g5sxxvDlmz
Je peux me connecter au socket TCP depuis mon compte.
DBUS_SESSION_BUS_ADDRESS=tcp:host=127.0.0.1,port=8004 notify-send hello
Mais pas de l'autre compte, ni avec dbus-monitor
ni avec notify-send
. Même message d'erreur dbus-monitor
que ci-dessus avec le socket abstrait; notify-send
émet maintenant une trace:
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 révèle que cette version de notify-send
n'essaie pas de lire le fichier cookie, donc je comprends pourquoi elle ne pourrait pas se connecter.
J'ai également essayé SSHing sur une autre machine et transféré la connexion TCP.
ssh -R 8004:localhost:8004 remotehost
Étonnamment, dbus-monitor
fonctionne sans fichier cookie! Je peux regarder le trafic D-Bus depuis l'hôte distant. Je vois un avis d'écoute dans mon dbus-monitor
instance locale .
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"
Si je cours notify-send
sur la machine locale, dbus-monitor
l'hôte distant voit la notification. Il a définitivement atteint un niveau d'accès qui devrait nécessiter une authentification.
notify-send
s'est plaint de ne pas avoir trouvé de cookie. Après avoir copié le fichier cookie, notify-send
fonctionne à partir de la machine distante.
La machine locale exécute Debian Wheezy. La machine distante exécute FreeBSD 10.1.
Je ne comprends pas comment fonctionnent l'authentification et l'autorisation D-Bus.
- Pourquoi puis-je écouter, pour autant que je sache, sans informations d'identification de la machine distante? Qu'est-ce que j'expose lorsque je transfère D-Bus vers une connexion TCP? Pourquoi les autorisations sont-elles
dbus-monitor
etnotify-send
différentes? - Pourquoi ne puis-je pas espionner d'un autre compte sur la même machine, que ce soit sur le socket abstrait ou sur la connexion TCP?
- J'ai remarqué que le fichier cookie change toutes les quelques minutes (je n'ai pas compris si c'est à intervalles réguliers ou non). Pourquoi?
(Je sais que je peux lancer un démon D-Bus qui écoute sur TCP. Ce n'est pas le but de ma question, je veux comprendre pourquoi ce que j'ai fait et n'a pas fonctionné.)
SCM_CREDENTIALS
spécifiquement. Sous Linux, il utiliseSO_PEERCRED
plutôt l'option socket.