Accessing Session Bus through the superuser
ozan at pardus.org.tr
Mon Mar 17 08:05:26 PDT 2008
Thiago Macieira wrote On 17-03-2008 14:02:
> On Monday 17 March 2008 12:48:40 Colin Walters wrote:
>> On Mon, Mar 17, 2008 at 3:38 AM, Thiago Macieira <thiago at kde.org> wrote:
>>> That's not a good practice. Instead, let the user connect to the system
>>> bus and receive the notifications there. Do not push messages into the
>>> session bus.
>> Right. Now the fact that a lot of people want the functionality to
>> broadcast notifications to the logged in session makes me think we
>> should probably add it to the system. But that's not a topic for this
> I think it is. And I also think that there already is a bus where system-wide
> notifications should be sent: the system bus.
> I still don't know of any good use-case to allow the root user -- or any user
> for that matter -- to connect to a user's session bus. Besides, that always
> brings the questions: which users? And which busses?
First of all, I'm completely aware that I'm abusing the well-defined
distinction between the system and session bus, but I'm just
experimenting. I saw two "slightly" different approaches trying to
connect to the session bus through the super user.
So here is my scenario:
I want to be able to notify a user when a new printer is plugged. I'm
currently using hal-cups-utils which provides a HAL callout triggered
by HAL when a new printer is connected. This callout checks whether the
printer has a corresponding CUPS queue. If not, it adds a new CUPS queue
and calls a method on System Bus, NewPrinter() with some arguments
containing printer make, model, driver, etc.
When the method is called, DBus activates(using system bus activation)
another python script which exports the object publishing this
NewPrinter() method. After successfully obtaining the arguments passed
by the HAL callout, this script tries to connect to session buses
available for notifying the user(s).
I'm just grepping "kdesktop" instances and parsing /proc/$pid/environ to
find out the corresponding values of DISPLAY, USER, and
DBUS_SESSION_BUS_ADDRESS.(I know it's too dirty and hacky but already
told, I just experiment).
>>> I don't either. The environment variable you set with the D-Bus
>>> session's bus address did not take effect. Review your script to see if
>>> setting the environment is working.
>> Most likely the existing session bus rejected authentication because
>> the root uid is not equal to the desktop user's uid.
> I don't think so. It's trying to run dbus-launch, which it only does if
> DBUS_SESSION_BUS_ADDRESS is empty or "autostart:".
I already told that everything works perfectly if I don't connect to
system bus for exporting something just before connecting to session
bus. The only thing that's confusing me is the stuff about the
mainloops. Can it be the cause which messes up bus connection instances?
The dummy test script is at for those who may want to take a look.
More information about the dbus