D-Bus User Bus

[Lennart Poettering]

On Wed, 19.05.10 22:12, Havoc Pennington (hp at pobox.com) wrote:

> 
> Hi,
> 
> 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.

Have you?

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)
different things.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4