Desktop Entry Specification - ExecuteAs proposition

Kevin Krammer kevin.krammer at
Sun Mar 7 09:02:42 PST 2010

On Sunday, 2010-03-07, PCMan wrote:
> On Sun, Mar 7, 2010 at 8:51 PM, Dario Freddi <drf54321 at> wrote:
> > I am not a big fan of this patch because (especially given what I've
> > written above) I don't see a use case.
> You personally don't use it doesn't means that others don't need it or
> there is no use case.
> It's widely used in SuSE and it's required by some Debian/Ubuntu packages,
>  too. It's especially useful when you have a simple program and the part
>  dealing with dbus + policykit support is even bigger than the program
>  itself. That's the use case.
> As I said previously, it's a matter of ``choice''. Developers can use
> policykit if they want, but don't prevent others from using sudo
> simply because you don't use it. Adding this key doesn't prevent
> developers from using policykit. It only adds usefulness for those who
> need it.

I agree that running something as a different user is quite nice sometimes, 
however very often it is used as a shortcut rather than being necessary, 
especially when the other user is root [1].

You are of course also right that adding such an option to the spec does not 
prevent anyone from using more sophisticated approaches, however  putting 
something into a spec can be interpreted of being a recommended approach.

One of the contexts of this proposed additions are file actions. These often 
are provided through other means than distribution packages (e.g. downloads).
An author of such an action could think that in order to make it work 
everywhere (different systems might have different security models) they would 
need to run the command as root. Effectively forcing all systems with more 
fine grained security models to reject any action asking for root, thwarting 
the original indent, or be dragged back to the level of less fortunate 

If this is added to the spec it should come with a big warning for both 
implementors as well as users, especially in the context of using root as a 
sledghammer approach.


[1] like installers deciding they need to be root when installing outside of 
$HOME without bothering to check whether the current user has enough 
priviledges aready, e.g. by group membership.
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <>

More information about the xdg mailing list