Bug 502804

I'm tending to close this as "won't fix" or "not a bug"

(In reply to comment #0)
> Fedora has a better framework now called PolicyKit. 
Is it really better? It's sound like PackageKit and PackageKit isn't a good thing!

I see no advantage for a switch to policykit right now. Let's talk about this in a few months or in a few releases.

What does your personal impression of PackageKit have anything to do with PolicyKit. They aren't even remotely related.

(In reply to comment #2)
> What does your personal impression of PackageKit have anything to do with
> PolicyKit. They aren't even remotely related.

Simon didn't say that they have anything to do with each other, he just mentioned the *sound* the same.

Many people have concernes about both PackageKit and PolicyKit, because they they require lot of overhead like dbus, 

Also I don't see any advantage of PolicyKit ATM. Can you configure it easily? Nope. Is there a desktop indepenend configuration tool? Nether. Deployment and management of large networks with PolicyKit? Never heared of that one.

If you really want convince Simon and Upstream to switch to PolicyKit, you should answer his question and list some real advantages of PolicyKit. And please show me something that states that consolehelper is deprecated.

BTW: The list at http://fedoraproject.org/wiki/Features/PolicyKitOne#Scope is way to short.

WebKit and PolicyKit might sound similar as well but it completely irrelevant what rhymes with which software. What you need to do look is the direct advantages of using PolicyKit.  I pointed to the wiki page because it the API reference and other details. 

If you want to see the advantages follow the thread starting at 

http://lists.freedesktop.org/archives/hal/2006-March/004770.html

where it was originally announced. Consolehelper is not used outside the Red Hat/Fedora circle and doesn't have desktop independent interfaces either. PolicyKit has a command line polkit-action and both gtk and qt frontends and bindings. Fedora is all about early innovation and linux environments dont necessarily publicize what they use and this is a basic infrastructure piece. So if you are going to wait for hearing in the press about large deployments using PolicyKit, that might never happen.

(In reply to comment #4)
> What you need to do look is the direct
> advantages of using PolicyKit.  I pointed to the wiki page because it the API
> reference and other details. 
> 
> If you want to see the advantages follow the thread starting at 
> 
> http://lists.freedesktop.org/archives/hal/2006-March/004770.html
> 
> where it was originally announced. 

I still don't see any real advantages after reading the wiki page and the mails you linked. Could you name a few please?

The only advantage I see is that the su problem is solved and X apps are no longer run as root. But David clearly states: "The 'su' problem should be solved upstream in a saner way than what is available today."

So my suggestion is: Nag upstream instead of the Fedora maintainer. Write a patch, wait until it is accepted upstream and then it will come back to Fedora automatically.

> Consolehelper is not used outside the Red
> Hat/Fedora circle and doesn't have desktop independent interfaces either.

usermode runs on the command line, so it certainly is desktop independent. 
usermode-gtk does not pull in anything that is not already installed on a Fedora install. It only requires GTK, which is impossible to remove (at least if you want something you can actually run with consolehelper).

Besides of that I was talking about configuration interfaces. consolehelper doesn't need a configuration GUI, because it's configuration is stored in simple text files. PolicyKit uses xml files scattered around on the system.

> PolicyKit has a command line polkit-action and both gtk and qt frontends and
> bindings. 

But the frontends pull in additional deps...

> Fedora is all about early innovation and linux environments dont
> necessarily publicize what they use and this is a basic infrastructure piece.

Fedora also is about following upstream, so please get this to another level.

> So if you are going to wait for hearing in the press about large deployments
> using PolicyKit, that might never happen.  

I was not talking about press releases but of *anybody* which includes people inside of Fedora or Red Hat. The criticism that PolicyKit cannot be deployed or managed in large environments originally comes not from me but from some of the RHEL server team guys who think that using PolicyKit is another step into to a desktop focused operating system that no longer can serve other purposes.

I don't expect the maintainer to directly implement the changes but to work with upstream on the improvements. The advantage is clearly noted in the mail, specifically the security advantages. With PolicyKit you can separate privileged actions with small helper applications and not run full fledged applications themselves as root. 

I already pointed out that PolicyKit has a command line interface as well. If it doesn't allow you to install just the command line interface separately, that' just the level of packaging granularity and you can report that as a enhancement request. There is no desktop neutral frontend possible but there are both qt and gtk frontends unlike consolehelper. 

Administrators are actually benefited by using this since they can set system wide policy for separate actions. For example, PackageKit uses PolicyKit and administrators can say, users are allowed to update their systems but not add or remove programs. I don't want to rely on heresay. Use it yourself directly and check it out. PolicyKit has already been adopted by other distributions unlike Fedora/Red Hat specific consolehelper.

(In reply to comment #6)
> The advantage is clearly noted in the mail,
> specifically the security advantages. 

IMO this is the only advantage. What other advantages you see?

> With PolicyKit you can separate
> privileged actions with small helper applications and not run full fledged
> applications themselves as root.

Yeah, fully agreed, but according to David this is upstream stuff.

> I already pointed out that PolicyKit has a command line interface as well. If
> it doesn't allow you to install just the command line interface separately,
> that' just the level of packaging granularity and you can report that as a
> enhancement request. There is no desktop neutral frontend possible but there
> are both qt and gtk frontends unlike consolehelper. 

polkit-action already is in the base PolicyKit package. The question is not for a cross desktop configuration tool but why there need to be frontends for configuration at all. What about a server not running X?

> Administrators are actually benefited by using this since they can set system
> wide policy for separate actions. For example, PackageKit uses PolicyKit and
> administrators can say, users are allowed to update their systems but not add
> or remove programs. 

You could easily do the same with pam and consolehelper, there are different configurations for "su" and "su -l" for example.

> I don't want to rely on heresay. Use it yourself directly
> and check it out. 

I tried and I failed. Maybe you could show us how to get the example working you just mentioned? Without any of the frontends of course, so we all can see how easy to use PolicyKit is.

> PolicyKit has already been adopted by other distributions
> unlike Fedora/Red Hat specific consolehelper.  

It has not been adopted, it has been developed at freedesktop.org right from the start. If Red Hat followed a more open development model back in the days where consolehelper was introduced, it probably would have been adopted by other distributions as well.

(In reply to comment #7)
> (In reply to comment #6)
> > The advantage is clearly noted in the mail,
> > specifically the security advantages. 
> 
> IMO this is the only advantage. What other advantages you see?

Security is the primary reason for the existence of the tool. So that's the obvious advantage

> polkit-action already is in the base PolicyKit package. The question is not for
> a cross desktop configuration tool but why there need to be frontends for
> configuration at all. What about a server not running X?

Seems a very odd question. For a server not running X, use the command line interface. The frontends existing for desktop environment to provide a user friendly interface.  Are you saying graphical frontends shouldn't exist at all?

> > Administrators are actually benefited by using this since they can set system
> > wide policy for separate actions. For example, PackageKit uses PolicyKit and
> > administrators can say, users are allowed to update their systems but not add
> > or remove programs. 
> 
> You could easily do the same with pam and consolehelper, there are different
> configurations for "su" and "su -l" for example.

Please read the original mail and the examples provided to understand how it is different. 

> I tried and I failed. Maybe you could show us how to get the example working
> you just mentioned? Without any of the frontends of course, so we all can see
> how easy to use PolicyKit is.

This is not like consolehelper. It is not a wrapper and doesn't work like one. The package maintainer has to work with upstream. 

> 
> > PolicyKit has already been adopted by other distributions
> > unlike Fedora/Red Hat specific consolehelper.  
> 
> It has not been adopted, it has been developed at freedesktop.org right from
> the start. If Red Hat followed a more open development model back in the days
> where consolehelper was introduced, it probably would have been adopted by
> other distributions as well.  

I would say the design is more important than where it is hosted. system-config-printer is hosted in fedorahosted.org but it adopted by other distributions like Ubuntu and Mandriva for example. Anyway, move this RFE upstream, please.

I don't want to discuss this anymore here.

(In reply to comment #8)
> Are you saying graphical frontends shouldn't exist at all?

No, but as I said before: A framework should not be that complicated that it requires frontends instead of a text editor for configuration.

> Please read the original mail and the examples provided to understand how it is
> different. 

I think you misunderstood me here. I know PolicyKit is different than the su like approach. I was not talking about using su to run applications but using consolehelper to run "su" and "su -l" because you claimed that PolicyKit is somehow more fine grained.

> This is not like consolehelper. It is not a wrapper and doesn't work like one.
> The package maintainer has to work with upstream. 

If you show the maintainer a working example of how much better and easier to configure PolicyKit is, he might be more motivated to invest time here. Also working together with upstream is not easy, see
http://cassmodiah.de/2009-05-17/a-hard-day-in-the-life-of-a-fedora-contributor/

> I would say the design is more important than where it is hosted.

Yes, and the design was discussed in public on freedesktop.org mailing lists unlike consolehelper.

> I don't want to discuss this anymore here.  

I see. But please be so kind as to show us how to easily implement the example you gave on the commend line. You are the one who filed this RFE, you claimed PolicyKit is superior and consolehelper deprecated, so you should be able to tell us in order to strengthen your POV. TIA!

One more thing:

(In reply to comment #6)
> There is no desktop neutral frontend possible but there
> are both qt and gtk frontends unlike consolehelper. 

No, these are KDE and Gnome frontends, not QT and GTK:

$ rpm -q --requires PolicyKit-gnome | grep gnome
gnome-vfs2 >= 2.4
libgnomevfs-2.so.0  
libpolkit-gnome.so.0
$ rpm -q --requires gnome-vfs2 | egrep -i 'gconf|gnome'
GConf2 >= 2.14
GConf2 >= 2.14
GConf2 >= 2.14
GConf2 >= 2.14
config(gnome-vfs2) = 2.24.0-3.fc10
gnome-mime-data >= 2.0.0-11
gnome-mount >= 0.4
libgconf-2.so.4  
libgnomevfs-2.so.0

http://fedoraproject.org/wiki/Features/PolicyKitOne#Scope lists gnome-session, but it also applies to lxsession and xfce-session. Now if these used PolicyKit they would also need PolicaKit-gnome for configuration, which pulls in all the gnome bits again. I'm sure this is not what both users and upstream developers want.

(In reply to comment #9)
> (In reply to comment #8)
> > Are you saying graphical frontends shouldn't exist at all?
> 
> No, but as I said before: A framework should not be that complicated that it
> requires frontends instead of a text editor for configuration

Command line interface exists. The frontends exist for desktop integration. You don't want desktop applications to fall back to a shell prompt for basic authentication prompts. 

> I think you misunderstood me here. I know PolicyKit is different than the su
> like approach. I was not talking about using su to run applications but using
> consolehelper to run "su" and "su -l" because you claimed that PolicyKit is
> somehow more fine grained.

su can only control whether a application on the whole is run as a particular user or not and it runs the whole application as a root user which is a significant problem as I have already explained to you. consolehelper is flawed because it just a wrapper that runs the whole application as root instead of giving fine grained access. It cannot control individual actions. Fire up polkit-gnome-authorization and take a look to understand how it is different. 

> If you show the maintainer a working example of how much better and easier to
> configure PolicyKit is, he might be more motivated to invest time here. Also
> working together with upstream is not easy

Sometimes, it is. Sometimes is is not but you haven't begin to have the conversation with upstream to know how well this is. If I spend a few hours convincing you and nothing goes to upstream, that's just effort wasted. I don't expect the package maintainer implement the code directly but merely have a conversation with upstream about their interest in this. It should require a huge discussion about this. It is a simple thing to file a RFE or shoot a email to the upstream developers and check out what they say. 
 
> > I would say the design is more important than where it is hosted.
> 
> Yes, and the design was discussed in public on freedesktop.org mailing lists
> unlike consolehelper.

You seem to think that discussing in freedesktop.org or hosting the software there somehow makes it more easy for cross distribution adoption. This is far from the case and all this is just a distraction from the current conversation.

Anyway, if you have already made up your mind otherwise, I can't convince you. This will be last interaction on this topic here. The responsible thing for a package maintainer is to take it upstream.

Added 'FutureFeature' keyword to avoid rawhide base

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

nssbackup project has been discontinued and its code merged back to sbackup. I've retired the package.

As there is already a similar bug filed for sbakcup, I think we could close this bug?