https://bugzilla.novell.com/show_bug.cgi?id=428963
User thoenig@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=428963#c62
--- Comment #62 from Timo Hoenig
The question is: Why does it want to access it?
The session bus is an important IPC mechanism for programs in the session We can't predict all the ways in which it will be used (it looks like in this particular case it's being used to access the user's configuration database).
This is still *way* to unclear. Looks like I'll sit down and have a tête-à-tête with the gconf code tomorrow morning. Before I do so -- do we agree on fixing gconf in case it uses libdbus for something which isn't required? Otherwise I'll skip that involuntary task.
By running anything which changes your identity (su $USER, gnomesu $APP, etc.) you're simply out of bounds of the current session.
It's not that clear-cut. The user needs to run programs as root on its current display, and the display is part of the session. The programs also need to talk to the session manager, e.g. so they can be told to quit when the session closes. There are other requirements, and I think the move to D-Bus as the session IPC mechanism (away from mechanisms like X display properties) will continue.
We're leaving ground -- it's a definition depending on each individuals point of few. In my opinion the session bus is part of the session and I have yet to see the *functional* requirement that another session needs to access it. Even if it is the very same user. Note: I use the wording 'session' calling 'su' is starting a new one from my point of view.
The ideal fix here would be to adopt a security model that doesn't require you to become a different user in order to accomplish vital tasks
I didn't think that I'd write something like this today in this discussion. But here it is: I completely agree.
- I'd be the first to admit that the "root" security model is broken - but insofar as we have to work within such a security model, we have to take a pragmatic approach.
Well, we have PolicyKit in place. It seems that it isn't used in our case -- we fail.
Re. dangerous: I don't see how exactly this would happen. If dbus-launch exposes session auth details to everyone, wouldn't that be a bug in D-Bus?
IIRC this was being done on purpose. I'd have to dig in the list archives to find out more.
So wouldn't that mean that you can already hijack anyone's session bus? That doesn't stand to reason in my mind. I'm fairly certain a user's session bus is supposed to be secure from other users on the host :)
No. Because knowing DBUS_SESSION_BUS_ADDRESS isn't enough. The session policy forbids another user to connect to it -- and that is, what has been loosen with your patch. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.