On 27/07/07, Damir Perisa wrote:

Friday 27 July 2007, Phil Dillon-Thiselton wrote: | We think gooeydo nicely addresses the problem by ensure that a | suitable "run as root" apps is used in all cases.

hmm... i think the .desktop files should have a flag that is handeled by the gui. it was suggested here first:

http://lists.freedesktop.org/archives/xdg/2005-August/thread.html#5651

but i don't know what happened since then.

Well, it looks like they hit the same snag - how do you know which of a multitude of run as root apps are available for that user? Even if there was a field in the .desktop file where you could add a run as root app you can't guarantee that every user/system will have it. That mean another layer of functionality outside the .desktop file which falls outside the FDS remit, I think.

gooeydo is a possibility... but it kind of feels like a work-around, no?

Well, it is a work around, but not really any more or less than sudo itself. It _feels_ hacky to me because it's just a bash script. Having said that 'which' is just some hacky bash and I use that every other day. There's not really an alternative though is there? Unlike ubuntu we don't use sudo as standard, and we won't, but yet we need a way to ensure that all our .desktop files work as expected for everyone within all DEs with their own implementations of run as root privs. At the very least I'd like to think it is nice, tidy, comprehensive workaround :-D Phil

On 27/07/07, Damir Perisa wrote:

the .desktop files are read by DE's for menu-making. the DE has usually a standard "su" tool. that's why i was thinking in the beginning, that this would be the ideal thing to handle needs-root conditions.

Hmmm, I guess that's true, but then I suppose it depends on a great degree of compliance by the DE creators and it also means users of those DEs are tied to that one method of launching apps, which I can't see being universally popular. Now, if all DEs had a facility for setting the run as root application, on a per user and even system wide basis, then we'd be talking! But what about WMs that just crib the .desktop files for desktop menus (openbox)? I can't see them wanting to include that sort of functionality. It's one of those awesome Linux grey areas where sheer variety causes standardisation problems.

but if gooeydo works, great for us! :)

Well, I hope so :-) It certainly does for _right now_, as brain0 would say... If no-one has any particular objections to this approach I'd be keen to throw it out and start implementing it ASAP. The dichotomous situation with wifi-radar and gparted is already icky enough for a "fix". Cheers, Phil

On 27/07/07, Damir Perisa wrote:

Friday 27 July 2007, Phil Dillon-Thiselton wrote: | Now, if all DEs had a facility for setting the run as root | application, on a per user and even system wide basis, then we'd | be talking! But what about WMs that just crib the .desktop files | for desktop menus (openbox)? I can't see them wanting to include | that sort of functionality.

how do they handle "run in terminal" options that can also be specified in desktop files? i wonder, because desktop files are not only menu entries but have also icon and categories and so on... so adding a wrapper for su/sudo/.. would be quite easy. kde has even the option "run as different user" in its menu entry options

| It's one of those awesome Linux grey areas where sheer variety | causes standardisation problems.

i would say lack of implementation rules causes it this time. if somebody wants to implement desktop files as source to running files based on them, this person should implement also things like run as different user / su.

| If no-one has any particular objections to this approach I'd be | keen to throw it out and start implementing it ASAP. The | dichotomous situation with wifi-radar and gparted is already icky | enough for a "fix".

one detail: how do you want this wrapper to work? the desktop files stay the same, right? or do you edit them to contain gooeydo instead of su/sudo/kdesu/.../?

The latter - I don't see how else we can do? James and I came up with this one morning so I'm not saying it's the ultimate solution, we could have overlooked plenty.

i still think, this should be dealt by the apps using desktop entries ... :-)

So do I...but how long will that take? Phil

Friday 27 July 2007, Phil Dillon-Thiselton wrote: | > one detail: how do you want this wrapper to work? the desktop | > files stay the same, right? or do you edit them to contain | > gooeydo instead of su/sudo/kdesu/.../? | | The latter - I don't see how else we can do?  James and I came up | with this one morning so I'm not saying it's the ultimate | solution, we could have overlooked plenty. true. i can only think of a stupid one: rename all su/sudo/... apps and put instead links to your wrapper that is configrable and runs the renamed desired one. | > i still think, this should be dealt by the apps using desktop | > entries ... :-) | | So do I...but how long will that take? i do not know the state of it but the freedesktop people should be shaken and reminded on it. i know that kde and probably gnome as well has started putting things like "run as another user" but they probably didnt consider putting it in desktop files... so either we specify it in desktop files and everybody does it the same way, or everybody reinvents the wheel... or even better for you - everybody uses your wrapper :) anyway... not much apps are having this issue, so it's managable to edit them by hand :) - D -- .·´¯`·.¸.·´¯`·.¸¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸¸.·´ ° ° ° ° ° ° ><((((º> ° ° ° ° ° <º)))>< <º)))><

On 27/07/07, Roman Kyrylych wrote:

2007/7/27, Damir Perisa :

...

Friday 27 July 2007, Phil Dillon-Thiselton wrote: | > one detail: how do you want this wrapper to work? the desktop | > files stay the same, right? or do you edit them to contain | > gooeydo instead of su/sudo/kdesu/.../? | | The latter - I don't see how else we can do? James and I came up | with this one morning so I'm not saying it's the ultimate | solution, we could have overlooked plenty.

true. i can only think of a stupid one: rename all su/sudo/... apps and put instead links to your wrapper that is configrable and runs the renamed desired one.

Well, I dunno how much you read but gooeydo is configurable on a per user basis, using a simple config, the type of config admins could add to skel and sleep soundly in there beds ;-)

ha, cruel :) I think it would be OK if xorg-clients depend on gooeydo (though not 100% users will install xorg-clients).

It would have to be a depends, yes, but it's a tiny pkg, probably barely 1k. And, once you've installed it once it's there when you need it. Phil

On Fri, Jul 27, 2007 at 10:45:51AM -0700, eliott wrote:

To me this all reminds me of debian's "alternatives" feature. Just an observation.

It pretty much is, only for one app and not for any app... While the alternatives feature was a good one, I don't know if we want it... it's a little confusing and complex. Jason

On 27/07/07, Jason Chu wrote:

On Fri, Jul 27, 2007 at 10:45:51AM -0700, eliott wrote:

...

To me this all reminds me of debian's "alternatives" feature. Just an observation.

It pretty much is, only for one app and not for any app...

While the alternatives feature was a good one, I don't know if we want it... it's a little confusing and complex.

I'd just like to clarify that gooeydo was conceived only for use in .desktop files, not as a general command line tool. I don't imagine that users would really be exposed to it, which is kind of bad, in terms of obfuscation.

On 7/30/07, Jason Chu wrote:

My Fedora contact told me about consolehelper which they use now and PolicyKit which they plan on moving to next release. PolicyKit actually looks pretty cool, even with desktop integration (using dbus, sorry Aaron). Gnome will be moving to PolicyKit soon. Hopefully KDE will follow.

PolicyKit is also an fd.o project, so it's pretty mainstream.

There aren't really any easy solutions to this. It's a tough problem that no one has solved generally.

Sounds a bit overboard. Seriously, Phil actually proposed a solution... he said "here's a script, do this", why are we looking for other solutions? Or is this premature optimization?

On 7/30/07, Jason Chu wrote:

...

Sounds a bit overboard. Seriously, Phil actually proposed a solution... he said "here's a script, do this", why are we looking for other solutions? Or is this premature optimization?

No, more worried about NIH.

I hate that acronym. It implies that you should always use stuff that other people made, which we all know is a terrible idea. I can cry NIH all day long. What is this pkg.tar.gz? Use debs! NIH! Why are these scripts in /etc/rc.d/, use init.d like everyone else! NIH! Archlinux? Why use that, use debian! NIH! Ok ok, rant over, but seriously, the only reason the NIH cry is applicable is when there is a _good_ solution in existence. You already stated that there are none. If the problem is not solved, if there is no solution, then the NIH claim is moot.

On 30/07/07, Jason Chu wrote:

Yeah, but the question is when will we implement another script that does the same sort of thing for (say) setting the desktop background?

I'm new to this business so, with the upmost respect: This is solution to an actual problem that exist _right now_ (tm). I don't think we're in any danger of accidently setting a precedent by going with any solution. We all know the fluidity of the situation and I think we know to base decisions on current circumstances.

If we just keep implementing similar scripts for the user to choose between equivalent alternatives, why don't we look at what other people are doing to solve the problem?

My Fedora contact told me about consolehelper which they use now and PolicyKit which they plan on moving to next release. PolicyKit actually looks pretty cool, even with desktop integration (using dbus, sorry Aaron). Gnome will be moving to PolicyKit soon. Hopefully KDE will follow.

PolicyKit is also an fd.o project, so it's pretty mainstream.

I'm not the smartest guy in the room but this looks to me like a new sudo/gksu/run as root auth system, rather than something to manage the multitude of existing run as root auth systems. It also looks like applications have to be built with support for it.

There aren't really any easy solutions to this. It's a tough problem that no one has solved generally.

Well, Ubuntu solved it by setting a standard. They use sudo, so I guess that they use sudo in all their .desktop files. We could do the same. We could even enforce the use of the trust group for applications such as wifi-radar and gparted. Any way we look at it I think we need to decide one way or another what we want to do and communicate the whys and wherefores to the community. We certainly shouldn't have .desktop files with a variety of auth systems in use.