Accessing Session Bus through the superuser

[Marcel Holtmann]

Hi Ozan,

>>>> 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
>>> list.
>>
>> 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[0] 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[1] 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).

see my comment on how we handle this inside BlueZ. The concept of a D- 
Bus agent can be applied to any cases and works perfectly fine. It is  
the most powerful usage of D-Bus when it comes to abstract UI  
processes from system process.

Regards

Marcel