D-Bus User Bus
mzqohf at 0pointer.de
Wed May 19 20:03:30 PDT 2010
On Wed, 19.05.10 22:12, Havoc Pennington (hp at pobox.com) wrote:
> On Wed, May 19, 2010 at 10:04 PM, Lennart Poettering <mzqohf at 0pointer.de> wrote:
> > Maybe as long as this only covers a gconf setting or two. But I am
> > pretty sure if actual data loss is involved then people would be pretty
> > pissed and ask "Why didn't warn me that app in advance?"
> What is the actual data loss beyond some settings?
think gnote/tomboy. Would you vouch that that tools is NFS safe? And
there are more systemd like that.
> > There are more things than just files that have to be managed:
> > hardware, network services, and so on. Think PA. Think Rygel. Think
> > gnome-user-share. gnome-bluetooth. telepathy. And so on. For them $HOME
> > on NFS is completely irrelevant, but they are inherently per-machine,
> > not per-session.
> I think this is the less-common case, compared to "every other app
> that isn't hardware-related" which is the common case.
well, I see it like this: we have three sets of processes on the bus:
1) those which are bound to $HOME (i.e. gconfd, eds)
2) those which are bound to the machine (i.e. everything that manages
hardware or offers a network service)
3) those which are bound to the display (i.e. all GUI apps, gnome-settings-daemon)
where sizeof(1) < sizeof(2) < sizeof(3).
> > I'd argue that parallel logins of the same user on the same machines is
> > way more likely than parallel network logins.
> Really? when is it useful? (other than ssh, anyway)
Nah, ssh is the answer here. I'd argue it is more commonly used than
shared NFS $HOME.
> > And that's reason enough to fix the local case even if the network
> > stuff is not really figured out. The NFS situation is borked anyway,
> > because we have no good channel for communication, and so on. And so
> > far nobody really cared about this,
> This is just not true. People have heavily cared about it in the past
> and flipped out when it broke.
Hmm? I am speaking of D-Bus here. I have never seen any realistic
approach to make D-Bus really network aware so that it is really bound
to the $DISPLAY.
What would the communication channel be?
> > I am strongly against mixing priviliged with unpriviliged services on
> > one bus. This is just a call for a security desaster.
> Most of the stuff on the system bus is not especially privileged, or
> has only the exact privs it needs. And all users/apps can connect to
> the system bus anyhow.
Well, using a bus service and providing a bus name are two (vastly)
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
More information about the dbus