question on <auth> and .dbus_keyrings
hp at redhat.com
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
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