Danek Duvall wrote:
On Tue, Apr 07, 2009 at 05:48:50PM +0100, jmr wrote:
Danek Duvall wrote:
On Tue, Apr 07, 2009 at 05:33:26PM +0100, jmr wrote:
You want this dbus session bus id to be shared by any instances of PM
or UM being run by root, so it needs to be located under /var/tmp. If
its put under a unique dir for each instance of PM or UM then it can't
be shared across the session, which is not the desired behavior.
Doesn't that imply that the name of the file is predictable? If so,
what happens if the file is already there and owned by someone else?
Seems like a vector ripe for attack.
The file is unique for the dbus session for that user on that machine:
~/.dbus/session-bus/9a0ea08dce46c0ecf3f16aa348525c34-0
So how can it be shared?
Its shared by running dbus as the user. Dbus manages it the user doesn't.
Aren't you creating it, though? Or at least pointing dbus at the directory
to create it in by setting $HOME? So if some other process needs to know
where to find this socket, how does it know where to go looking?
DBus will create the file if required in the user's Home dir under
~/.dbus/session-bus/, other apps running for that user that indirectly
use dbus by say calling a gconf access function will also be using dbus
and presumably it will check the same location for this user, see the
file and use it as the shared session bus. I haven't dug into the dbus
code to confirm this, but functionally that's what appears to be happening.
What if I'm su'ed to another user?
We are running PM and UM with pfexec from the menu, to be functional you
need to run them as root. This is what this fix is about.
Can you explain the scenario that is of concern.
It's only a side issue -- if I run pm as myself, everything's okay, though
I can't do anything useful. If I run pm elevated to root, everything's
okay. But if I su to another user, then the getuid() check returns false
(I'm not root), so I don't reset $HOME to someplace I can write to, and I
have the same problem that we're having now.
Well it does seem like a side issue I agree. With Michal's patch for the
gconf error handling, all that will happen is that this instance of PM
will fail to get any saved settings for PM from gconf and fall back to
the defaults. So PM will still be able to run and will not crash as it
did before.
Danek
_______________________________________________
pkg-discuss mailing list
pkg-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
