per-user dbus

[Ryan Lortie]

Hi

What was the last word on the idea of having a DBus daemon instance scoped
to the user instead of the session?  I have a use for this[1].

For those worried about an explosion in the number of processes running we
could offer a simple alternative: if your system never has more than one
session for a given user, then we make DBUS_BUS_SESSION == DBUS_BUS_USER.

Cheers




[1]:
I have an elaborate scheme for dconf whereby activating the user's second
dconf-writer on a session bus (ie: one is already running in a different
session) results in the first instance connecting to the second session bus
(ie: one dconf-writer instance connected to multiple session bus
instances).  This system *almost* works but dconf's use of DBus match rules
to "watch without activating" means that changes could be happening in one
session and not be signaled in the other (here they are being watched for)
merely because the second session doesn't know about the writer and the
writer doesn't know about the second session until a *write* occurs in that
session, causing the connection to be made.

_______________________________________________
dbus mailing list
dbus@...
http://lists.freedesktop.org/mailman/listinfo/dbus

[Lennart Poettering-2]

On Sun, 08.11.09 13:27, Ryan Lortie (desrt@...) wrote:

> Hi

Heya!
 
> What was the last word on the idea of having a DBus daemon instance scoped
> to the user instead of the session?  I have a use for this[1].

I have started hacking on this, but have never finished it. It is
however on my todo list, and one of the more important items.

While some folks seem not to particularly like the idea (Hey, Colin!)
I got the feeling the general consensus was that it does make sense
and the patch could go in.

There is a substantial amount of D-Bus code in PulseAudio now that
uses the session bus as a placeholder of a future user bus. All that code I
cannot declare official or stable or anything until the user bus is
properly introduced. So I am quite eager to see the user bus
being done.

Here's what I came up with how this thing should work to be robust and
stable and not accidentaly leak user busses:

dbus-launch should get two switches: --user and --session, which can
be (and normally are) specified at the same time. The --session switch
should expose the current behaviour (and should be the default when no
switch is passed, for compat reasons), however when --user is passed a
user bus will be spawned. For that dbus-launch will talk to a tiny
auto-spawned dbus system service that can be used to spawn user
busses. That tiny service only has a single method "GetUserBus()"
whith no arguments. It will create a new user bus for the user
calling, and returns its address or return the address of an existing
bus if there already is a user bus for the calling user. It will keep
track of clients that have issued that call and reference count the
bus with that. That means the user bus is started when the first
"dbus-launch --user" is run, and is killed when the last instance of
it dies.

By way of dbus-launch we can make sure that we don't leak user busses,
the same was we make sure we don't leak session busses.

--exit-with-session should probably be implied by --user since if
dbus-launch does not stay around the user bus would be killed
right-away.

So, to enable the user bus all that is needed is that all dbus-launch
invocations in X11 startup scripts are fixed to pass "--user" and
"--session".

This scheme should be quite robust as the lifecycle of the user bus is
bound to the same logic as the lifecycle of the session bus is
currently bound to.

It seems crucial to me that the user bus is spawned from a process
that lives outside the user's session, so that it can start from a
fresh environment, and is completely detached from the user session.

There are some issues to keep in mind though: spawning user code is
relevant to system security, so we probably need to call into PAM
before allowing the user bus to be run under the user's uid. I think
cron does something similar for all user cronjobs is executes.

> For those worried about an explosion in the number of processes running we
> could offer a simple alternative: if your system never has more than one
> session for a given user, then we make DBUS_BUS_SESSION ==
> DBUS_BUS_USER.

I think that would be a bad idea and mostly a source of errors, and a
futile attempt to satisfy the requests of some folks whose requests
cannot be satisfied anyway.

Anyway, I am really interested to the the user bus become reality. If
you want to work on this, I'd be happy to review things or help in any
other way. Otherwise I hope I'll eventually find the time to dust off
the work I started and finish it.

Lennart

--
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4
_______________________________________________
dbus mailing list
dbus@...
http://lists.freedesktop.org/mailman/listinfo/dbus

[Colin Walters]

On Mon, Nov 9, 2009 at 5:16 PM, Lennart Poettering <mzqohf@...> wrote:
>
> While some folks seem not to particularly like the idea (Hey, Colin!)

Well, it's not that I don't like the idea of a per-(kernel,uid) bus,
it's more that I think that's what the "session" bus should be.

In other words, if we have _USER, what should still be using _SESSION?

> For that dbus-launch will talk to a tiny
> auto-spawned dbus system service that can be used to spawn user
> busses.

Would make sense to have this in the system bus process I think (but a
new dbus interface, say org.freedesktop.DBusManagement?  better naming
suggestions?)

> That tiny service only has a single method "GetUserBus()"
> whith no arguments. It will create a new user bus for the user
> calling, and returns its address or return the address of an existing
> bus if there already is a user bus for the calling user. It will keep
> track of clients that have issued that call and reference count the
> bus with that. That means the user bus is started when the first
> "dbus-launch --user" is run, and is killed when the last instance of
> it dies.

Sounds reasonable.

> There are some issues to keep in mind though: spawning user code is
> relevant to system security, so we probably need to call into PAM
> before allowing the user bus to be run under the user's uid. I think
> cron does something similar for all user cronjobs is executes.

You mean run pam_session?  I'd rather avoid being in the business of
running PAM modules.   We're going to be called through gdm, cron, and
ssh which will already be running pam_session.
_______________________________________________
dbus mailing list
dbus@...
http://lists.freedesktop.org/mailman/listinfo/dbus

[Lennart Poettering-2]

On Tue, 10.11.09 10:37, Colin Walters (walters@...) wrote:

>
> On Mon, Nov 9, 2009 at 5:16 PM, Lennart Poettering <mzqohf@...> wrote:
> >
> > While some folks seem not to particularly like the idea (Hey, Colin!)
>
> Well, it's not that I don't like the idea of a per-(kernel,uid) bus,
> it's more that I think that's what the "session" bus should be.
>
> In other words, if we have _USER, what should still be using
> _SESSION?

Yes, I think so. I am quite confident that things like multiple SSH or
other kinds of remote logins will continue to exist for a long, long
time. I.e. there will be graphical logins and some "reduced
functionality" logins, such as SSH, and they will live side by
side. I don't think it is likely that we will be able to support multi
full-session logins by the same user anytime soon, or even if it would
be worth doing that. But those reduced functionality (i.e. tty) logins
will be supported for a longer time.

Also, I'd like to draw the distinction between session and user buses
also in terms of network. I.e. i still believe we should try to make
the session bus shared across the network, while the user bus is
per-machine.

> > For that dbus-launch will talk to a tiny
> > auto-spawned dbus system service that can be used to spawn user
> > busses.
>
> Would make sense to have this in the system bus process I think (but a
> new dbus interface, say org.freedesktop.DBusManagement?  better naming
> suggestions?)

Yepp, might make sense, but due to the involvement of all that PAM and
other security sensitive stuff I thought it felt nicer if this was
handled out-of-process. But then again, this is only an implementation
detail.

> > There are some issues to keep in mind though: spawning user code is
> > relevant to system security, so we probably need to call into PAM
> > before allowing the user bus to be run under the user's uid. I think
> > cron does something similar for all user cronjobs is executes.
>
> You mean run pam_session?  

Yes.

> I'd rather avoid being in the business of running PAM modules.
> We're going to be called through gdm, cron, and ssh which will
> already be running pam_session.

I am not really sure we have an option. If we spawn things from
outside the session all user limits set for it, yadda yadda will not
apply. Now, that is good thing on one hand, but a bad thing on the
other, since stuff like /usr/security/limits.conf would be ignored for
user bus activated servcies. And that is probably not an option.

There is a substantial amount of ugliness in all of this. PAM sucks
anyway, but the fact that we call into the session hooks of PAM for
something that is explicitly not a session is particularly ugly. But
then again, I think it is easy enough to be pragmatic about this.

Lennart

--
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4
_______________________________________________
dbus mailing list
dbus@...
http://lists.freedesktop.org/mailman/listinfo/dbus

[Colin Walters]

On Tue, Nov 10, 2009 at 12:42 PM, Lennart Poettering <mzqohf@...> wrote:
>
> Yes, I think so. I am quite confident that things like multiple SSH or
> other kinds of remote logins will continue to exist for a long, long
> time. I.e. there will be graphical logins and some "reduced
> functionality" logins, such as SSH, and they will live side by
> side.

So what's the reason we want those to have separate bus instances?  I
certainly want, when I have a login session running, then ssh into the
computer, to access the existing session data.   Or if my backup job
kicks off, it'd sure be nice to pick up the gnome-keyring from my
running desktop.

On the other hand, the only use case for having them actually be
separate that I can think of offhand is "poor man's virt" like xnest
testing.  And for the testing case, it's trivial to explicitly spawn a
separate bus when you want it.

> Also, I'd like to draw the distinction between session and user buses
> also in terms of network. I.e. i still believe we should try to make
> the session bus shared across the network, while the user bus is
> per-machine.

So you're arguing for the dbus-embedded-in-X11 approach for say ssh+X
forwarding?  That would be a pretty radical change to introduce into
the stack at this point.

I guess what I really don't like is if we added _USER in addition to
_SESSION, claimed the big difference was network transparency, but 5
years later no one had actually implemented the ssh forwarding.

> I am not really sure we have an option. If we spawn things from
> outside the session all user limits set for it, yadda yadda will not
> apply. Now, that is good thing on one hand, but a bad thing on the
> other, since stuff like /usr/security/limits.conf would be ignored for
> user bus activated servcies. And that is probably not an option.

Hmm, right.  I think we need advice here from a PAM expert about the
different kinds of things that can go on in pam_sesson, whether it's
possible to use it without first running through the auth stack, etc.
_______________________________________________
dbus mailing list
dbus@...
http://lists.freedesktop.org/mailman/listinfo/dbus

[Lennart Poettering-2]

On Tue, 10.11.09 13:22, Colin Walters (walters@...) wrote:

>
> On Tue, Nov 10, 2009 at 12:42 PM, Lennart Poettering <mzqohf@...> wrote:
> >
> > Yes, I think so. I am quite confident that things like multiple SSH or
> > other kinds of remote logins will continue to exist for a long, long
> > time. I.e. there will be graphical logins and some "reduced
> > functionality" logins, such as SSH, and they will live side by
> > side.
>
> So what's the reason we want those to have separate bus instances?  I
> certainly want, when I have a login session running, then ssh into the
> computer, to access the existing session data.   Or if my backup job
> kicks off, it'd sure be nice to pick up the gnome-keyring from my
> running desktop.

I believe that gnome-keyring data is inherently per-user and not
per-session. gnome-keyring is one of those services that should move
from session to user and have the same lifecycle as the user bus:
i.e. as long as at least one dbus-launch is running.

> On the other hand, the only use case for having them actually be
> separate that I can think of offhand is "poor man's virt" like xnest
> testing.  And for the testing case, it's trivial to explicitly spawn a
> separate bus when you want it.

Nah. I tried to leave open what "reduced functionality" actually
refers to. Could by a simple SSH tty. Could be a something involving X
too. Probably not a full GNOME session however.

The question what belongs on the user bus and what on the session
bus is the big question here. I think the general answer goes like
this: anything that involves a specific X11 display belongs on the
session bus, everything else (i.e. that is independant of the X11
display) belongs on the user bus.

gnome-panel's dbus interface is certainly something for the session,
same is true for gedit, the notification daemon, vino, gnote,
nautilus, and others. They all have windows on the screen, and are
singleton services of the X11 display.

OTOH dconf, geoclue, gvfs or telepathy don't have windows on the
screen and deal with data that is shared among sessions. They should
live on the user bus.

X11 displays can be shared on the network, and that's precisely the
reason why I believe session busses should be shared too, and follow
the same access policy.

> > Also, I'd like to draw the distinction between session and user buses
> > also in terms of network. I.e. i still believe we should try to make
> > the session bus shared across the network, while the user bus is
> > per-machine.
>
> So you're arguing for the dbus-embedded-in-X11 approach for say ssh+X
> forwarding?  

Kinda. Given that X-in-ssh is the most canonically used access mode
for remote X these days I'd actually suggest adding a new switch to
ssh, i.e. -U or so that forwards the bus in parallel to X. That
appears more elegant to me, since the half-synchronous X stuff cannot
interfere with dbus then as the two channels are completely
independant and we dont end up with an ugly stack of stacked
protocols...

> That would be a pretty radical change to introduce into
> the stack at this point.

Would it really? I am not sure it would. Sure some things would break,
i.e. if they mix FS access with D-Bus. But tbh I am quite sure we'd
have gotten this kind of brokeness even if we had gone
network-transparent from the beginning.

Also, it should be easy to extend the access policy stuff a little so
that network access could be forbidden to those "broken" services.

> I guess what I really don't like is if we added _USER in addition to
> _SESSION, claimed the big difference was network transparency, but 5
> years later no one had actually implemented the ssh forwarding.

It would probably make sense to propose that patch for SSH too at the
same time as the one for the user bus.

> > I am not really sure we have an option. If we spawn things from
> > outside the session all user limits set for it, yadda yadda will not
> > apply. Now, that is good thing on one hand, but a bad thing on the
> > other, since stuff like /usr/security/limits.conf would be ignored for
> > user bus activated servcies. And that is probably not an option.
>
> Hmm, right.  I think we need advice here from a PAM expert about the
> different kinds of things that can go on in pam_sesson, whether it's
> possible to use it without first running through the auth stack, etc.

Cron does exactly that. So it is doable.

Lennart

--
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4
_______________________________________________
dbus mailing list
dbus@...
http://lists.freedesktop.org/mailman/listinfo/dbus

[Simon McVittie-6]

On Wed, 11 Nov 2009 at 01:39:40 +0100, Lennart Poettering wrote:
> OTOH dconf, geoclue, gvfs or telepathy don't have windows on the
> screen and deal with data that is shared among sessions. They should
> live on the user bus.

One problem we've seen in a real-world use of D-Bus is that if you have two
D-Bus connections, you lose the total-ordering guarantees. As a result, if any
of an app's functionality goes over the user bus, that whole "module" should
use the user bus.

This is tricky in Telepathy, because we do rely on the bus's total-ordering
guarantee for the correct operation of Clients (UIs, basically), to get
events delivered to a Client in an order that doesn't leave it guessing about
the context of something it's being asked to do. So, if we move the channel
dispatcher (Mission Control) to the user bus, Empathy's Client interface
(by which Mission Control tells it to handle a particular channel) would also
have to move to the user bus.

For a while, Maemo's libdbus was broken in such a way that if you asked for
the session bus and for the starter bus, you got two DBusConnection instances
pointing at the same bus. Half of a Client's functionality went over
each of those, resulting in races between reads from the two sockets, and
messages sometimes happening "in the wrong order" - it took a long time to
debug this, and for a while we even suspected that dbus-daemon was reordering
the messages!

Another practical point about the user bus is that the bus to be on should
be considered to be part of the API/ABI, so changing it should be a "flag day"
like any other API break (in the case of Telepathy we'd wait until we're
breaking API anyway, which we plan to do once before Telepathy 1.0).

    Simon
_______________________________________________
dbus mailing list
dbus@...
http://lists.freedesktop.org/mailman/listinfo/dbus

[Ray Strode]

Hi,

On Tue, Nov 10, 2009 at 10:37 AM, Colin Walters <walters@...> wrote:
> On Mon, Nov 9, 2009 at 5:16 PM, Lennart Poettering <mzqohf@...> wrote:
>>
>> While some folks seem not to particularly like the idea (Hey, Colin!)
>
> Well, it's not that I don't like the idea of a per-(kernel,uid) bus,
> it's more that I think that's what the "session" bus should be.
>
> In other words, if we have _USER, what should still be using _SESSION?
The session bus serves a very useful purpose, it defines the scope of
the user's session.  I think that was one of it's original design
intents (right Havoc?).

There are various bits of infrasture that hook themselves to the
lifecycle of the bus because they expect that the bus will only
survive for the duration of the user's session.
I don't think we can break that gaurantee.

Having a separate user bus may make sense for limited number of cases,
but i don't think it makes sense to replace the session bus with a
user bus.

What might make sense is having a way for programs to add themselve to
the session without their parent being in the session.  I could
imagine, if DBUS_SESSION_BUS_ADDRESS wasn't set, looking for the first
available running session bus for the user (how? kernel keyring? X
property?) and joining it.  This would solve the
cron-can't-access-my-session-even-when-i'm-logged-in problem.
Although, I think that problem would better be solved by
gnome-settings-daemon or some other session daemon just providing cron
like functionality.

I do think the number of cases where a user bus is useful is pretty
small.  I'm not saying those cases are invalid, but we shouldn't try
to shoehorn other cases into the user bus bucket.

--Ray
_______________________________________________
dbus mailing list
dbus@...
http://lists.freedesktop.org/mailman/listinfo/dbus

[Jörg Barfurth]

Lennart Poettering schrieb:

>>> There are some issues to keep in mind though: spawning user code is
>>> relevant to system security, so we probably need to call into PAM
>>> before allowing the user bus to be run under the user's uid. I think
>>> cron does something similar for all user cronjobs is executes.
>> You mean run pam_session?  
>
> Yes.
>
>> I'd rather avoid being in the business of running PAM modules.
>> We're going to be called through gdm, cron, and ssh which will
>> already be running pam_session.
>

> I am not really sure we have an option. If we spawn things from
> outside the session all user limits set for it, yadda yadda will not
> apply. Now, that is good thing on one hand, but a bad thing on the
> other, since stuff like /usr/security/limits.conf would be ignored for
> user bus activated servcies. And that is probably not an option.
>
> There is a substantial amount of ugliness in all of this. PAM sucks
> anyway, but the fact that we call into the session hooks of PAM for
> something that is explicitly not a session is particularly ugly. But
> then again, I think it is easy enough to be pragmatic about this.
>

Following the model of cron probably makes sense here. What you start
could be considered a 'service session', as it is a process (tree)
running on behalf of a user, but outside any interactive session.

Running session stack only is probably not sufficient. pam_setcred is in
the auth stack, but may also be part of setting things up correctly for
a user - on (Open)Solaris pam_unix_cred sets up project, privilege sets
and audit context.

- Jörg

--
Joerg Barfurth
Software Engineer        mailto:joerg.barfurth@...
Desktop Technology
Thin Client Software     http://www.sun.com/software/sunray/
Sun Microsystems GmbH    http://www.sun.com/software/javadesktopsystem/

Sitz der Gesellschaft:
Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten
Amtsgericht Muenchen: HRB 161028
Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Wolf Frenkel
Vorsitzender des Aufsichtsrates: Martin Haering

_______________________________________________
dbus mailing list
dbus@...
http://lists.freedesktop.org/mailman/listinfo/dbus

[Simon McVittie-6]

On Wed, 11 Nov 2009 at 13:17:32 +0000, Simon McVittie wrote:
> On Wed, 11 Nov 2009 at 01:39:40 +0100, Lennart Poettering wrote:
> > OTOH dconf, geoclue, gvfs or telepathy don't have windows on the
> > screen and deal with data that is shared among sessions. They should
> > live on the user bus.
>
> One problem we've seen in a real-world use of D-Bus is that if you have two
> D-Bus connections, you lose the total-ordering guarantees. As a result, if any
> of an app's functionality goes over the user bus, that whole "module" should
> use the user bus.

I didn't make my point very clearly, so I'll try to explain better...

Normally, a D-Bus API between some cooperating processes can rely on total
ordering of messages. In Telepathy we rely on this in some places.

For instance, we have a concept of Handlers (UIs, basically) that can handle
Channels (e.g. calls). A Client making a request is given a method return
with the path of an object representing the request. Later (potentially,
minutes or hours later, which is partly why we don't just use a long-running
method call) it's told to handle the Channel that resulted from the request,
by exactly the same API that would be used if the Channel had not been
requested.

The request's object path is given as an extra parameter, so UIs can relate
the channel to the request if they want to. To make this work, we guarantee
that the return from the Client's method call (with the object path) will
arrive before the HandleChannels method call (which refers to that object
path).

However, that guarantee is impossible if you read the method reply and the
method call from two different sockets, which is what one of the Maemo UIs
accidentally found itself doing (it made the method call for the request on
the starter bus, but took its well-known name on the session bus, and due
to a bug, those were not the same DBusConnection behind the scenes).

Indeed, you can't even rely on causal ordering between two different sockets -
the events happen in the right order, but are queued inside dbus-daemon, the
kernel and the applications, and the messages are popped from those queues in
an arbitrary order that depends on implementation details and even on the
kernel scheduler.

There are two ways this problem could manifest itself with a user bus:

* The user bus is the same as a particular session's bus, but libdbus
  doesn't realise that, and makes two sockets. This is solvable - libdbus
  solves it for the "starter" pseudo-bus already (possible bugs aside) -
  so it doesn't concern me much.

* The user bus is not the same as the session bus, but a "module" (e.g.
  Telepathy, viewed as a whole) is split between the two. Here, the race
  between reading the two sockets is unavoidable. The same problem exists
  between any pair of buses, like the system and session buses, but those
  have well-defined (and very different) scopes, so it's not a problem
  in practice - people don't tend to design APIs that rely on the relative
  order of system and session events.

I hope that's somewhat clearer!
    S
_______________________________________________
dbus mailing list
dbus@...
http://lists.freedesktop.org/mailman/listinfo/dbus

[Jörg Barfurth]

Colin Walters schrieb:

> On Tue, Nov 10, 2009 at 12:42 PM, Lennart Poettering <mzqohf@...> wrote:
>> Yes, I think so. I am quite confident that things like multiple SSH or
>> other kinds of remote logins will continue to exist for a long, long
>> time. I.e. there will be graphical logins and some "reduced
>> functionality" logins, such as SSH, and they will live side by
>> side.
>
> So what's the reason we want those to have separate bus instances?  I
> certainly want, when I have a login session running, then ssh into the
> computer, to access the existing session data.   Or if my backup job
> kicks off, it'd sure be nice to pick up the gnome-keyring from my
> running desktop.
>
> On the other hand, the only use case for having them actually be
> separate that I can think of offhand is "poor man's virt" like xnest
> testing.  And for the testing case, it's trivial to explicitly spawn a
> separate bus when you want it.
>

I don't think you should exclude the case of two graphical sessions.

There are real desktop virt (thin client) systems (e.g. our Sun Ray)
that have the sessions on the server. It is quite easy to obtain more
than one graphical session that way.

Existing problems with that are not substantially different from those
you get when running two sessions on different hosts that use a common
networked home directory. And depend on the desktop environment you are
using.

>> Also, I'd like to draw the distinction between session and user buses
>> also in terms of network. I.e. i still believe we should try to make
>> the session bus shared across the network, while the user bus is
>> per-machine.
>

If the optimal scope for a session bus is everything accessing the same
X server, would the optimal scope for a user bus be everything accessing
the same home directory - even if that is shared or replicated over the
network?

Maybe I don't really understand the use case yet. As for things
mentioned in this thread:
- keyring: I probably want to share my keyring as widely as my home
directory. But I don't want to share an unlocked key access handle to my
keyring beyond my current session.
- PulseAudio: I don't see anything audio-specific that I want to have
user-scope. Audio sources and sinks are generally associated with
sessions, not users.

One thing where a user bus would really make sense is user preferences
(i.e. dconf). But there again home directory scope is a better fit than
user-at-host scope. For configuration both system and clients would need
to properly distinguish sharable, local and transient settings - but
currently we don't. That is one reason why the attempt to do networked
gconf didn't work out too well.

- Jörg

--
Joerg Barfurth           phone: [phone] / x66662
Software Engineer        mailto:joerg.barfurth@...
Desktop Technology       http://reserv.ireland/twiki/bin/view/Argus/
Thin Client Software     http://www.sun.com/software/sunray/
Sun Microsystems GmbH    http://www.sun.com/software/javadesktopsystem/


_______________________________________________
dbus mailing list
dbus@...
http://lists.freedesktop.org/mailman/listinfo/dbus

[Stef Walter]

Lennart Poettering wrote:
> I believe that gnome-keyring data is inherently per-user and not
> per-session. gnome-keyring is one of those services that should move
> from session to user and have the same lifecycle as the user bus:
> i.e. as long as at least one dbus-launch is running.

Makes sense.

One problem would be that of API breakage.

For example, we're now finalizing the DBus Secret Service API (which
gnome-keyring will use in the future). It's being implemented on the
session bus. To later move it to another (new) bus would be a
significant API break, wouldn't it?

It seems this would be the case for many other deployed DBus APIs.

Cheers,

Stef

_______________________________________________
dbus mailing list
dbus@...
http://lists.freedesktop.org/mailman/listinfo/dbus

[Havoc Pennington-3]

There's a ton of user bus discussion in archives. While there are some  
use cases most of the good ones require a true user bus not a user-
machine bus. Let's face it most things are per user on all machines or  
per all users on one  machine.

I think a user bus would attract stuff that should be designed per  
session. Having session and system already confuses the hell out of  
people.

It's just too complex relative to value.   Work around its absence.  
That's my opinion.

If you did do it, name it user-machine bus not user bus please.

On Nov 11, 2009, at 9:51 AM, Ray Strode <halfline@...> wrote:

> Hi,
>
> On Tue, Nov 10, 2009 at 10:37 AM, Colin Walters <walters@...>  
> wrote:
>> On Mon, Nov 9, 2009 at 5:16 PM, Lennart Poettering <mzqohf@...
>> > wrote:
>>>
>>> While some folks seem not to particularly like the idea (Hey,  
>>> Colin!)
>>
>> Well, it's not that I don't like the idea of a per-(kernel,uid) bus,
>> it's more that I think that's what the "session" bus should be.
>>
>> In other words, if we have _USER, what should still be using  
>> _SESSION?
> The session bus serves a very useful purpose, it defines the scope of
> the user's session.  I think that was one of it's original design
> intents (right Havoc?).
>
> There are various bits of infrasture that hook themselves to the
> lifecycle of the bus because they expect that the bus will only
> survive for the duration of the user's session.
> I don't think we can break that gaurantee.
>
> Having a separate user bus may make sense for limited number of cases,
> but i don't think it makes sense to replace the session bus with a
> user bus.
>
> What might make sense is having a way for programs to add themselve to
> the session without their parent being in the session.  I could
> imagine, if DBUS_SESSION_BUS_ADDRESS wasn't set, looking for the first
> available running session bus for the user (how? kernel keyring? X
> property?) and joining it.  This would solve the
> cron-can't-access-my-session-even-when-i'm-logged-in problem.
> Although, I think that problem would better be solved by
> gnome-settings-daemon or some other session daemon just providing cron
> like functionality.
>
> I do think the number of cases where a user bus is useful is pretty
> small.  I'm not saying those cases are invalid, but we shouldn't try
> to shoehorn other cases into the user bus bucket.
>
> --Ray

_______________________________________________
dbus mailing list
dbus@...
http://lists.freedesktop.org/mailman/listinfo/dbus

[Colin Walters]

On Wed, Nov 11, 2009 at 2:51 PM, Ray Strode <halfline@...> wrote:
>
> What might make sense is having a way for programs to add themselve to
> the session without their parent being in the session.  I could
> imagine, if DBUS_SESSION_BUS_ADDRESS wasn't set, looking for the first
> available running session bus for the user (how? kernel keyring? X
> property?) and joining it.  This would solve the
> cron-can't-access-my-session-even-when-i'm-logged-in problem.

ConsoleKit or the system bus would make the most sense here I think.
Though if we do this for the session bus, it also raises the question
about DISPLAY.

Lennart, if auto-joining was implemented, would it help your user bus
use cases?  What *are* those use cases exactly actually?
_______________________________________________
dbus mailing list
dbus@...
http://lists.freedesktop.org/mailman/listinfo/dbus

[Havoc Pennington-2]

If you really want to melt your brain on this topic, realize that it
basically requires some decisions on that "what does su do" bug. I
still think certain cases will have to be proven impossible / declared
unsupported to close that one.

The big reason for a session bus, not (user,machine) bus historically,
was that old-KDE had everything per-session and largely Just Worked
with NFS and multiple sessions, while old-GNOME was trying to do
various stuff per-(user,machine) - or some really broken hacks trying
for true per-user - and was breaking horribly with multiple sessions.

If developers don't really think about multiple logins or NFS,
per-session tends to mostly work as expected, while per-(user,machine)
tends to get really hosed because a program has to be aware of
multiple X servers and sessions to work properly if it's scoped
per-(user,machine). Unfortunately, if there's something called
DBUS_BUS_USER I think lots of devs will think "oh, I should use that"
for something like config settings. But in all likelihood, they should
not use it, because it will just fail - it would only "magically work"
in the right way if it were per-user, not per-(user,machine).

per-(user,machine) is pretty much only useful for hardware-related
stuff. Otherwise it needs to be per-user, not per-(user,machine).

Havoc
_______________________________________________
dbus mailing list
dbus@...
http://lists.freedesktop.org/mailman/listinfo/dbus

[Colin Walters]

On Wed, Nov 11, 2009 at 3:24 PM, Joerg Barfurth <Joerg.Barfurth@...> wrote:
>
> There are real desktop virt (thin client) systems (e.g. our Sun Ray) that
> have the sessions on the server. It is quite easy to obtain more than one
> graphical session that way.

I thought the Sun Ray had portable sessions?  The "Hot Desk Mobility"
at http://www.sun.com/sunray/sunray270/features.xml certainly makes it
sound like it does.  Can you really get two login sessions on a Sun
Ray setup?
_______________________________________________
dbus mailing list
dbus@...
http://lists.freedesktop.org/mailman/listinfo/dbus

[Colin Walters]

On Fri, Nov 13, 2009 at 3:27 PM, Havoc Pennington <hp@...> wrote:
>
> The big reason for a session bus, not (user,machine) bus historically,
> was that old-KDE had everything per-session and largely Just Worked
> with NFS and multiple sessions,

I wouldn't call it "Just Works" personally.   NFS and multiple
sessions give you the Last One Wins behavior, which is a pretty quick
path to data loss under any real-world usage besides "Oh look, I can
log into the desktop twice!" demos.  Open an openoffice document on
display/session A, go to another department/home, log in again on
display B, try to access your document, make a quick modification
forgetting you had it open in session A...
_______________________________________________
dbus mailing list
dbus@...
http://lists.freedesktop.org/mailman/listinfo/dbus

[Havoc Pennington-2]

Hi,

On Fri, Nov 13, 2009 at 11:30 AM, Colin Walters <walters@...> wrote:
>
> I wouldn't call it "Just Works" personally.   NFS and multiple
> sessions give you the Last One Wins behavior, which is a pretty quick
> path to data loss under any real-world usage besides "Oh look, I can
> log into the desktop twice!" demos.  Open an openoffice document on
> display/session A, go to another department/home, log in again on
> display B, try to access your document, make a quick modification
> forgetting you had it open in session A...
>

That's true but it's way better than what happened with bonobo,
gconfd, etc.  (i.e. total failure to work _at all_ - the complexity of
apps and daemons having to manually deal with multiple displays - i.e.
sessions - was totally over the top and they never were able to)

(If we want to set some UI policy I think it's somewhat fair game to
declare two X sessions for same user on same machine to be
Wrong/Useless, which means that multiple session buses only arises for
console/ssh - irrelevant for most apps - and for multiple machines.
This makes a (user,machine) bus even more useless. And the
"openoffice.org editing same document twice" problem is just not
solveable a across multiple machines, so I'd say just punt it.)

The bottom line is that 1 X server, 1 session, 1 user is a nice simple
model that apps get right; everything else is underspecified,
underdocumented, poorly understood, etc. App devs _might_ get it right
if there were clear guidelines, but as we can see on the "su" bug,
nobody has a frickin clue how this is supposed to work. And it _can't_
work in every case people can think of, all at once. Some of the cases
have to lose. Which means some decisions and some docs are required.
Or, we can leave the status quo which is basically, people don't try
to log in more than once if they're sensible ;-)

Havoc
_______________________________________________
dbus mailing list
dbus@...
http://lists.freedesktop.org/mailman/listinfo/dbus

[Havoc Pennington-2]

And again, if you do add a user bus, you really really want it to be
DBUS_BUS_USER_KERNEL_PAIR or something very explicit, so devs are
forced to stop and think "oh, what does that mean and what are the
implications..." while with DBUS_BUS_USER they might just think
"perfect!" and try using that for everything under the sun when it's
basically not very useful and should not be used in most cases.

Havoc
_______________________________________________
dbus mailing list
dbus@...
http://lists.freedesktop.org/mailman/listinfo/dbus

[Jörg Barfurth]

Colin Walters schrieb:
> On Wed, Nov 11, 2009 at 3:24 PM, Joerg Barfurth <Joerg.Barfurth@...> wrote:
>> There are real desktop virt (thin client) systems (e.g. our Sun Ray) that
>> have the sessions on the server. It is quite easy to obtain more than one
>> graphical session that way.
>
> I thought the Sun Ray had portable sessions?  The "Hot Desk Mobility"
> at http://www.sun.com/sunray/sunray270/features.xml certainly makes it
> sound like it does.  Can you really get two login sessions on a Sun
> Ray setup?

Sun Ray sessions are identified by "tokens". A token can be a smartcard
or an authenticated username (usually without smartcard). If one user
uses multiple smartcards or uses card and cardless sessions, they get
multiple sessions. I know of use cases where that is used to have
multiple sessions for different purposes. Or cardless use may be a
fallback, when you forgot the card elsewhere.

- Jörg


--
Joerg Barfurth           Phone: [phone]
Software Engineer        mailto:joerg.barfurth@...
Desktop Technology
Thin Client Software     http://www.sun.com/software/sunray/
Sun Microsystems GmbH    http://www.sun.com/software/javadesktopsystem/

Sitz der Gesellschaft:
Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten
Amtsgericht Muenchen: HRB 161028
Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Wolf Frenkel
Vorsitzender des Aufsichtsrates: Martin Haering

_______________________________________________
dbus mailing list
dbus@...
http://lists.freedesktop.org/mailman/listinfo/dbus