autostart spec updates/extensions

[Dan Winship]

There was a thread in February and March about extensions to the
autostart spec[1], but nothing ever happened with it.

There were three points being discussed then, and a few more I'd like
to try to address as well.


1. XDG_CONFIG_DIRS or XDG_DATA_DIRS?

First up was discussion of what the right place for autostart .desktop
files was. The spec currently says autostart files are read from
$XDG_CONFIG_DIRS/autostart. Some people apparently didn't like this,
because all other .desktop files are in $XDG_DATA_DIRS. Waldo argued
that that's irrelevant, because in this case, they're being used as a
configuration mechanism, not as application data. This seems right to
me. The problem was also raised that $XDG_DATA_DIRS/autostart would
collide with the pre-fdo KDE autostart system, which causes problems
because of apps that aren't marked OnlyShowIn=KDE, but should be if
they're in what's considered to be a system-wide directory.

So I'd argue with sticking with $XDG_CONFIG_DIRS/autostart. Is anyone
really horribly opposed to this?

(FWIW, GNOME currently looks first in $XDG_DATA_DIRS/gnome/autostart,
and then in $XDG_CONFIG_DIRS/autostart. According to the ksmserver
README, KDE looks in "$KDEHOME/share/autostart", and AFAICT from the
source code, this is correct; I don't think it looks at $XDG_DATA_DIRS
at all, and I don't think it does fdo-autostart out of any user
directories. (~/.kde/Autostart is different from fdo-autostart in
numerous ways.))


2. Immutability / Lockdown

We want some way for the administrator to lock down certain aspects of
autostart. (Eg, "you can't remove this app from the startup items
list".)

KDE already has a widely-used system for marking part or all of a
.desktop file immutable, and that gets used by their autostart system
already, so there's a strong argument for just adopting that.

Basically the system is:

	- if a key has [$i] at the end of the name, it's immutable
	  (can't be changed or deleted)
	- if a group name has [$i] after it (eg, [Desktop Entry][$i]),
	  the whole group is immutable (no keys can be changed, added,
	  or deleted)
	- if the file has [$i] as its first group name, the whole file
	  is immutable

It was suggested that you can then make an autostart file unremovable
by adding

	Hidden[$i]=false

to the system version of it. But this isn't really true, because the
user could just change the Exec line to run something else instead, or
add a TryExec field pointing to a non-existent binary, or who knows
what else. So basically you have to mark either the whole [Desktop
Entry] group immutable, or the whole file. (I think? Anyone got an
exploit against that?)

Are there other lockdown cases we need to deal with? In KDE, has
immutability in autostart been used for anything other than
you-can't-remove-this-from-the-session? Have there been requests for
other features?

If the only case we really need to support is "lock down the whole
file", then we could cheat and add a change to the autostart spec
saying that if the .desktop file starts with an empty group named
"[$i]", then the file is immutable. If we need to be able to put [$i]
in other places for reasonable use cases, then it probably makes more
sense to update the Desktop Entry Specification itself to add
immutability, although this is a non-backward-compatible change to the
syntax of .desktop files, so that might not fly.


3. X-KDE-autostart-condition

KDE lets you specify that an app should only be started if a certain
kconfig setting is set, eg:

    X-KDE-autostart-condition=kgpgrc:User Interface:AutoStart:false

which means that the app should only run if the "AutoStart" setting in
the "User Interface" group of the "kgpgrc" config file is true (and if
it's not set, assume it's "false").

This seems incredibly useful, except for the obvious
KDE-specificness... There doesn't see to be a "One Config System To
Rule Them All" on the horizon, but I think we can still standardize
this. Given that KDE sessions are likely to be mostly filled with KDE
apps and GNOME sessions are likely to be mostly filled with GNOME
apps, etc, we ought to be able to punt on making this fully desktop
agnostic. Something like:

    Autostart-Condition

    An application that only wants to be started if a certain
    configuration setting is set can use the Autostart-Condition key
    as a hint:

        Autostart-Condition: config-system:key

    "config-system" specifies one of the following configuration
    systems:

	kconfig: KDE's KConfig system. The key name consists of the
	  config file, group name, key name, and default value,
	  separated by ":".

	gconf: GNOME's GConf system. The key name is a gconf path,
	  which must point to a boolean-valued key. The schema
	  determines the default value.

	exists: The key name is a filename relative to
	  $XDG_CONFIG_HOME; if the file exists, the key is "true".

    Autostart files MAY use config-system values not specified here,
    if they start with "x-" or "X-".

    Eg:
      Autostart-Condition: kconfig:kgpgrc:User Interface:Autostart:false
      Autostart-Condition: gconf:/desktop/gnome/remote_access_enabled
      Autostart-Condition: exists:MyApp/autostart
      Autostart-Condition: x-environment-variable:$FOO_ENABLED

    There is no guarantee that the desktop environment launching the
    desktop file will be able to handle configuration keys of a given
    type (and in particular, desktop environments do not need to
    implement ANY of the config-system values described above). Thus,
    an application using this mechanism MUST still check the value of
    the configuration setting itself when it starts up, and exit if
    the key is not set.

and add to Appendix C, "Deprecated Items":

    "X-KDE-autostart-condition: foo" means the same thing as
    "Autostart-Condition: kconfig:foo"

(Another possibility would be that rather than specifying any
desktop-specific config systems in the spec itself, just say that
config-system names use reverse dns naming or something, and KDE would
use "org.kde.kconfig" for its keys and GNOME would use
"org.gnome.gconf" for its, and there would just be links from the
autostart spec page on freedesktop.org to the pages that specified how
those worked.)

Anyway, the idea is that as long as the session manager isn't
launching too many apps with unrecognized key types (which should be
the normal case), then having the apps get started anyway and then just
exiting when they check the key themselves won't be too awful.

Furthermore, in the gconf case, it would always be possible for a
non-GNOME SM to just use "gconftool-2" to fetch the value of the key.
(Is there a corresponding command-line tool for kconfig?) This might
be especially useful for the "minor" desktops, since their users are
probably more likely to be running apps from other desktops.


4. Other KDE extensions?

Are there any other extensions from KDE autostart that we should
absorb? The only other one I'm aware of is X-KDE-autostart-phase.

Having some sort of priority/phase system seems like a good idea.


5. "autostop"[2]

Running stuff at logout (eg, cleaning up stuff?). Does KDE do anything
with this currently? Do people really have good use cases for this
(which couldn't just as easily be solved via XSMP-based logout
notification)?


6. autorun/autoopen

WTF??? The autorun/autoopen-on-volume-mount stuff is completely
unrelated to autostart-at-login. Anyone opposed to booting this out
into a separate spec?


7. XSMP

I noticed that KDE had someone hacking on XSMP-related stuff for
Summer of Code. Is that stuff likely to be adopted?

Given that XSMP and autostart are closely tied together, and given
that XSMP is annoyingly underspecified, it seems to me like it might
be nice to put some XSMP clarifications into the autostart spec
(though maybe others would feel that this is just as out of place as
the autorun stuff?)

A few specific examples:

	- The KDE/GNOME consensus on what Local/Global/Both
          SaveYourselfs mean[3]

	- Interpretation of SaveYourselfDone(FALSE). (KDE interprets
          this as meaning that it should cancel the shutdown. GNOME
          ignores it. This used to be an interop problem, as
          GnomeClient returned FALSE by default if the app didn't
          implement the save_yourself signal, but that was eventually
          fixed.)

There are probably others. (Oh, I just discovered that ksmserver
doesn't use SmEnvironment when restarting saved apps, and in fact, the
XSMP spec never actually says that you're supposed to... sigh.)

-- Dan


[1] http://lists.freedesktop.org/archives/xdg/2006-February/007795.html, etc
http://lists.freedesktop.org/archives/xdg/2006-March/007807.html, etc

[2] from another thread in April:
http://lists.freedesktop.org/archives/xdg/2006-April/008091.html

[3] http://www.redhat.com/archives/xdg-list/2002-July/msg00095.html