musings on session service mgmt
 

On Thu, 2008-01-03 at 20:39 -0500, Havoc Pennington wrote:
> This may be obvious, but the "correct" solution is supposed to be that
> apps should connect to either the X server or the session message bus
> and they should exit when the X server or message bus does. (Both Xlib
> and libdbus exit on disconnect by default for this reason.)

Of course...

> Other solutions are pretty much hacks, I mean, they may be worthwhile
> and pragmatic hacks, but, nonetheless. Apps should be exiting with the
> session already or they are buggy.

... but people write all sorts of weird apps, they have religious
reasons for not wanting deps.. that, and as soon as you require people
to add code to their app then everything falls apart.

> I would think this should only be done after the session bus is gone and
> apps have had a chance to cleanly exit, and maybe some kind of warning
> should be logged like "crappy app xyz had to be killed"

Certainly. The proposed ordering would guarantee this (00 < 01). I'm a
big fan of logging this to syslog too.

David


--
Fedora-desktop-list mailing list
Fedora-desktop-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-desktop-list

musings on session service mgmt
 

David Zeuthen wrote:
> Also, since we're talking about environment variables, we surely need to
> care about the ordering; e.g. we want
>
> 00-ck-xinit-session.sh
> 01-dbus-session-bus.sh
> 10-ssh-agent.sh
> 10-seahorse-agent.sh
>
> and so forth.

That still doesn't work though; dbus-daemon won't have access to
$SSH_AGENT or $GPG_AGENT_INFO, and so therefore neither will any
applications that it launches. (We already have this problem with
$SESSION_MANAGER.)

The only real solution is "don't use environment variables for long-term
IPC". Eg, libgnomekeyring used to use an environment variable to find
gnome-keyring-daemon, which ended up meaning that dbus-launched apps
couldn't access gnome-keyring, but now it's been fixed to use dbus
instead. But yeah, we're not going to get gpg and ssh to use dbus, I know.

The "new-gnome-session" branch in SVN (which Lucas Rocha is hacking on,
but it looks like won't make it in time for 2.22?) has a dbus interface
(org.gnome.SessionManager.Setenv) that lets apps that start very early
in the startup process hand environment variables back up to the session
manager so that apps started after them will see those vars. If
dbus-daemon itself also supported something like this, that would help
solve the ordering issues somewhat (though still not entirely).

-- Dan

--
Fedora-desktop-list mailing list
Fedora-desktop-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-desktop-list

musings on session service mgmt
 

Hi,
> > Also, since we're talking about environment variables, we surely
> > need to care about the ordering; e.g. we want
> >
> > 00-ck-xinit-session.sh
> > 01-dbus-session-bus.sh
> > 10-ssh-agent.sh
> > 10-seahorse-agent.sh
> >
> > and so forth.
>
> That still doesn't work though; dbus-daemon won't have access to
> $SSH_AGENT or $GPG_AGENT_INFO, and so therefore neither will any
> applications that it launches. (We already have this problem with
> $SESSION_MANAGER.)
>
Those scripts get sourced before dbus daemon is launched.

--Ray

--
Fedora-desktop-list mailing list
Fedora-desktop-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-desktop-list

musings on session service mgmt
 

Hi,

> Assuming problem 2. will be magically solved for us (see below), we
> could nicely rearrange the flow such that SSH_AGENT, DBUS_LAUNCH,
> CK_XINIT_SESSION could just use standard constructs
> in /etc/X11/xinit/xinitrc.d/.
I actually have that written on my whiteboard as a TODO when I get time.

> Another observation is that only stuff using environment variables
> should use /etc/X11/xinit/xinitrc.d/ (some man page should spell this
> out) - everything else should use the XDG autostart spec (where we
> have UI, e.g. gnome-session-properties).
>
> Also, since we're talking about environment variables, we surely need
> to care about the ordering; e.g. we want
>
> 00-ck-xinit-session.sh
> 01-dbus-session-bus.sh
> 10-ssh-agent.sh
> 10-seahorse-agent.sh
>
> and so forth. Again, the man page should be clear about this. Also,
> there should be a README file in /etc/X11/xinit/xinitrc.d/ that
> points to the man page.
>
> Instead of exec'ing gnome-session, we run it in the background. When
> we are done we run the same scripts in reverse just with 'stop'
> instead of 'start' as the first positional parameter.
Starting to seem a lot like initscripts... Anyway, definitely could be
improvement here, but I don't think we should promote this directory
too much. We really want apps using the session bus instead of their
own socket protocol and an environment variable to advertise where it
is.

Really this directory is an escape hatch for programs that don't
leverage our platform.

> I think this is a pretty small project that could be done in a few
> days, maybe a week.
Much bigger, more important fish to fry right now.

--Ray

--
Fedora-desktop-list mailing list
Fedora-desktop-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-desktop-list

musings on session service mgmt
 

Hi,

On Thu, 2008-01-03 at 20:10 -0500, David Zeuthen wrote:
> Notably, 00-ck-xinit-session.sh will take care of problem 2. The way it
> does this is because of the way that ConsoleKit works. It basically will
> just kill all the processes where the uid and the environment variable
> XDG_SESSION_COOKIE matches. First it tries SIGTERM. Then after a few
> seconds, it moves on to SIGKILL (e.g. -9).
>
> (of course, any process can unset XDG_SESSION_COOKIE and then fork and
> that way linger on. But no sane process would do that unless it's
> hostile.)

Not in the least, there are programs which are supposed to stay running
even when you log out -- screen, vncserver, nohup'ed processes etc. Mind
that non-desktop oriented projects might not be that inclined to work
around the "desktop strangeness du jour" (background processes being
killed when logging out would count as such).

On Thu, 2008-01-03 at 20:39 -0500, Havoc Pennington wrote:
> This may be obvious, but the "correct" solution is supposed to be that
> apps should connect to either the X server or the session message bus
> and they should exit when the X server or message bus does. (Both Xlib
> and libdbus exit on disconnect by default for this reason.)

This would solve the problem above more cleanly.

Nils
--
Nils Philippsen / Red Hat / nphilipp@redhat.com
"Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759
PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011

--
Fedora-desktop-list mailing list
Fedora-desktop-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-desktop-list

musings on session service mgmt
 

On Fri, 2008-01-04 at 16:14 +0100, Nils Philippsen wrote:
> On Thu, 2008-01-03 at 20:39 -0500, Havoc Pennington wrote:
> > This may be obvious, but the "correct" solution is supposed to be that
> > apps should connect to either the X server or the session message bus
> > and they should exit when the X server or message bus does. (Both Xlib
> > and libdbus exit on disconnect by default for this reason.)
>
> This would solve the problem above more cleanly.

Except that a decade of evidence shows us this is not the case.... but I
guess you'd rather want the status quo, with all the security issues and
perceived instability, rather than a working and secure system...

(But then again, this is the typical story of the Linux desktop; we
can't ever change or fix a thing because people who use the desktop in
rather strange (dare I even say perverse?) ways (e.g. expecting
processes to keep running) will start complaining as soon as we change
something that will break their highly-customized setups and habits. Do
not pass start. Do not collect $100. Instead let the naysayers and
status quo win.)

David


--
Fedora-desktop-list mailing list
Fedora-desktop-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-desktop-list

musings on session service mgmt
 

On Fri, 2008-01-04 at 16:14 +0100, Nils Philippsen wrote:

> Not in the least, there are programs which are supposed to stay running
> even when you log out -- screen, vncserver, nohup'ed processes etc.

No one is talking about changing the semantics of "nohup".

What we're talking about it is that it is actually hard to write apps to
exit with the session when that's what is the desired behavior.

--
Fedora-desktop-list mailing list
Fedora-desktop-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-desktop-list

musings on session service mgmt
 

Ray Strode wrote:
> Hi,
>>> Also, since we're talking about environment variables, we surely
>>> need to care about the ordering; e.g. we want
>>>
>>> 00-ck-xinit-session.sh
>>> 01-dbus-session-bus.sh
>>> 10-ssh-agent.sh
>>> 10-seahorse-agent.sh
>>>
>>> and so forth.
>> That still doesn't work though; dbus-daemon won't have access to
>> $SSH_AGENT or $GPG_AGENT_INFO, and so therefore neither will any
>> applications that it launches. (We already have this problem with
>> $SESSION_MANAGER.)
>>
> Those scripts get sourced before dbus daemon is launched.

*currently*. But that's exactly what David is talking about changing.
(Note the ordering above.)

-- Dan

--
Fedora-desktop-list mailing list
Fedora-desktop-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-desktop-list

musings on session service mgmt
 

On Fri, 2008-01-04 at 10:22 -0500, David Zeuthen wrote:
> On Fri, 2008-01-04 at 16:14 +0100, Nils Philippsen wrote:
> > On Thu, 2008-01-03 at 20:39 -0500, Havoc Pennington wrote:
> > > This may be obvious, but the "correct" solution is supposed to be that
> > > apps should connect to either the X server or the session message bus
> > > and they should exit when the X server or message bus does. (Both Xlib
> > > and libdbus exit on disconnect by default for this reason.)
> >
> > This would solve the problem above more cleanly.
>
> Except that a decade of evidence shows us this is not the case.... but I
> guess you'd rather want the status quo, with all the security issues and
> perceived instability, rather than a working and secure system...

Show me why your proposal (which you admitted can be circumvented
easily) is better or more secure than fixing the handful of programs
that don't end themselves when the session exits. If we don't talk about
hostile processes which actively circumvent, we're talking about dumb
processes. These should be fixed rather than declaring stuff which up to
now worked correctly as erroneous just to avoid doing the fixing. Where
is the difficulty in letting these handful of processes either connect
to dbus, X11 or the session manager and bail out if the connection dies?
I'm curious.

> (But then again, this is the typical story of the Linux desktop; we
> can't ever change or fix a thing because people who use the desktop in
> rather strange (dare I even say perverse?) ways (e.g. expecting
> processes to keep running) will start complaining as soon as we change
> something that will break their highly-customized setups and habits. Do
> not pass start. Do not collect $100. Instead let the naysayers and
> status quo win.)

David, you need to accept that there are people who use computers
differently than you think they should. This doesn't make them second
class users. Only because an approach is different from what exists
already, that doesn't make it better. I like to think that much can be
achieved without hurting existing users. If that makes me a naysayer, it
makes you a yeasayer which is almost equally bad ;-).

Nils
--
Nils Philippsen / Red Hat / nphilipp@redhat.com
"Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759
PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011

--
Fedora-desktop-list mailing list
Fedora-desktop-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-desktop-list

musings on session service mgmt
 

On Fri, 2008-01-04 at 11:10 -0500, Colin Walters wrote:
> On Fri, 2008-01-04 at 16:14 +0100, Nils Philippsen wrote:
>
> > Not in the least, there are programs which are supposed to stay running
> > even when you log out -- screen, vncserver, nohup'ed processes etc.
>
> No one is talking about changing the semantics of "nohup".

Perhaps I'm a bit slow, but how would it not do this if it relies on the
inheritance of a previously non-existent environment variable that needs
to be deleted if a process shall not be killed on session exit?

> What we're talking about it is that it is actually hard to write apps to
> exit with the session when that's what is the desired behavior.

I still don't understand why this would be the case. I assume what Havoc
wrote is true, i.e. stuff that uses xlib or dbus is already covered. How
is it difficult to let the remaining handful of processes die when the
session exits? We could even let these few register themselves with
gnome-session (or whatever else is applicable) so it could explicitly
kill them on session exit, couldn't we?

Nils
--
Nils Philippsen / Red Hat / nphilipp@redhat.com
"Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759
PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011

--
Fedora-desktop-list mailing list
Fedora-desktop-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-desktop-list