OLPC and .service files in a users home directory

[Thiago Macieira]

Havoc Pennington wrote:
>Hi,
>
>Using the XDG_ locations makes sense to me. Maybe something like
>  <servicedir xdg_relative="true">relative/path</servicedir>
>?

Makes sense, but I'd say no one in his right mind should change this 
configuration.

Say we start using the default as 
	<servicedir xdg_relative="true">dbus-1/services</servicedir>

People will start making packages that install service files 
to /usr/share/dbus-1/services. Changing the servicedir entry in the 
config will make all those applications stop being activatable.

We could instead do:
	<servicedir usexdg="true" />
to make dbus use the $XDG_DATA_{HOME,DIRS} entries at that point. This 
would allow the admin to append or prepend directories, in order to 
provide defaults or override settings.

>I've seen a couple side mentions of merging .service and .desktop; can
>someone fill me in on the goal of that? Other than the two both being in
>.ini format, I don't see the similarity...

The fact that they are so very similar. We have many .desktop editors as 
well as validation tools.

We are also discussing on xdg at lists.freedesktop.org using .desktop files 
for program autostart (when the desktop starts).

What I fail to see is why we should have a different format when there 
already is one that suffices.

There's also the fact that the D-Bus service activation looks a lot like 
the KDE service files: they are in $KDEDIRS/share/services (which is the 
same as $XDG_DATA_DIRS/services in most cases), they are .desktop files 
and they have some keys for finding plugins.

In the future, I'd like to suggest the [$i]-mode lockdown too.

>Re: cascading config - is there any reason to install config files for
>the session bus? For the system bus it's only the security policy stuff.

Oh, sorry, that's not what I meant.

By "cascading config", I didn't mean the dbus-daemon's settings, but the 
service definition files. I'd like to see them work like the desktop 
menu, again in .desktop fashion. That means a file with the same name in 
a higher-priority directory inherits and merges all the config, then 
simply overriding what was set before.

Another thing that has come to mind: Hidden=true should disable the 
service file.

>John, you mentioned also doing this for the system bus. Allowing system
>bus policy files in homedirs doesn't seem conceivably secure though?

This doesn't make sense to me. The system bus is run either as the root 
user or as another unprivileged user. It would be that user's 
$HOME/.local/share that would be scanned for D-Bus service and policy 
files.

A user without privileges shouldn't be able to change the policy for 
privileged exchange of information.

>I'd think that on a system allowing homedir installs, there are
>conceptually a couple different kinds of thing to install. 1) OS
>components or "drivers" that have to be in the trusted core - this may
>even be locked down and third party vendors should not expect to be able
>to install this stuff 2) "apps" that anyone can install

Exactly what I meant. If the user is installing a program or tool that 
changes/adds/deals with privileges, he has to elevate his own privileges 
for that (= type the root password).

>Anyway, I don't think any of this can block 1.0 unless it's a lot
>smaller than expected...

-- 
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/dbus/attachments/20061030/28b3cc40/attachment.pgp