If you look at Pirut or any of the system-config-* tools in Fedora, the line about "system policy" is instead some along "This program needs more privileges' instead of saying "This access is being denied". I think that is more clear than the current bold title.

Sure, this is a PolicyKit-gnome string, not a PackageKit choice. Talking to DavidZ might result in better translations, I'm not sure how the UI is put together.

Actually the string "System policy prevents install file" is what you provide in the .policy file; see the docs for details :-). So it's really a PackageKit string... I suck at naming and coming up with user-friendly language so I can't advice you on something better.

(also, you want to remember to the .policy.in file add it to po/POTFILES.in (need intltool>=0.36) to get it translated; see the PolicyKit-gnome repo for details).

It's also worth noting that you can configure your system for 'wheel' group access (like Mac OS X) when there is no root password on the system; that's documented too and it amounts to adding an element define_admin_auth (with the attribute group="wheel" or user="davidz|pat" or whatever) to /etc/PolicyKit/PolicyKit.conf and then you'll get a dialog like this where one of the administrative users (according to define_admin_auth) can be selected.

It's probably the right choice to avoid allowing people to keep the privilege (cf. this dialog) but if an admin wanted he could even do this on a per-user basis in /etc/PolicyKit/PolicyKit.conf using the match elements (again, refer to the man page). Conversely, you can also arrange that some users will never even get to see the dialog. So there's a lot of options :-)

As you can see, there's a lot of ground to cover. To help you zero in on the changes that interest you the most, I've divided the rest of this review into sections on Design, Efficiency, Collaboration, and Workflow.

this is why gnome needs something like UAC.

typing passwords all the time sucks :(

the way i see this is it's a workaround for a bug rather than a fix. the bug being that there's no way of propagating information in the system such as "the user just clicked on this file", all the way from the X server through gdk/gtk/nautilus to the backend, so that a script won't be able to abuse it.

pop up this dialog enough times and the user quickly gets trained to type their password into any dialog no matter what it says.

>so that a script won't be able to abuse it

But we want this to be scriptable. Installing stuff from scripts != virus. If the user is trusted, they can click the little tickybox and never have to enter the password again.

I meant that if a script wants to install something, then the user would get the password dialog alright. but in the case when they actually clicked on the rpm, there's enough information to determine that the system should go right ahead and install the package, don't you think?

  If they don't get enough, they should go back to school and get a better paying job. On the particular evening referred to above, our waitress wasn't horrible - she just wasn't great.

Come on, lets educate people who do not know the joys of Linux and especially Ubuntu  Sarangan Thuraisingham wrote on : (permalink) I see this bug time to time.

Why change something that does all anyone needs. " After all, that's what some people said about Windows Windows XP and Vista.