Accessing Session Bus through the superuser

[Ozan Çağlayan]

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

> 
>>>  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[3] for those who may want to take a look.

Thanks all.

[0]:
https://bugs.launchpad.net/ubuntu/+source/smartmontools/+bug/16386
http://lists.freedesktop.org/archives/galago-devel/2007-April/000078.html

[1]: http://svn.fedorahosted.org/svn/hal-cups-utils/
[2]: http://svn.pardus.org.tr/pardus/playground/ozan/dist/notify.py

-- 
Ozan CAGLAYAN
http://cekirdek.pardus.org.tr/~ozan
<ozan_at_pardus.org.tr>