question on <auth> and .dbus_keyrings

Havoc Pennington hp at
Tue Jun 27 20:51:15 PDT 2006

Thiago Macieira wrote:
> Technically, it has bitten me when porting kdesu. I had simply to remove 
> the feature that allowed a differently-privileged program to connect to 
> the calling user's session bus (DCOP server, in the case).
> However, changing the code to match the comment won't help in all cases, 
> since kdesu can be used to run programs with a non-root privilege as 
> well.

Most of the time right now it seems to work to do "dbus-launch foobar" 
which gives foobar its own private little bus... most foobar will run OK 
in that case, though obviously if foobar actually _requires_ desktop 
services it won't work ;-)

> What would be interesting to me would be to be able to tell the session 
> bus server to accept connections given a certain cookie that I would set 
> in the DBUS_SESSION_BUS_ADDRESS variable. kdesu would be responsible for 
> retiring the cookie when no longer needed, or for pinging the server to 
> make sure it doesn't expire.

I think this is perhaps a nicer and more general approach than just 
hardcoding "root is OK" - though allowing root doesn't really decrease 
security in my mind (root could just su to your account, obviously), it 
also doesn't "solve for good" this issue.

This could be done by just adding another auth mechanism.

(Are env variables always hidden from other users though? I don't really 

Could also do the X11 type thing, where you have to merge your xauth 
cookies across or whatever. Or could have a config file in the homedir 
which is "users allowed to connect to my session bus." Various plausible 
ways to do this...

If nobody is going to work on this pretty soon though, maybe we should 
let root through in a hardcoded way just because it's the most common 
case (e.g. running a system config tool).


More information about the dbus mailing list