On Wed, 2007-08-22 at 10:34 -0400, Jesse Keating wrote:
For me it's not asking the users these questions, it's asking
for their password to proceed (with a timeout). OSX does this, and we
seem to base a lot of our "good usability" on what they do.
friend wants to just look at their web mail, why should they switch
users to a guest account? Why can't I just hand them the laptop and
let them use the already running browser?
Because you don't want your auto completion / browser history (e.g.
porn), already existing sessions (banks, social networks, gmail, other
sites) made available to your friends?
If something popped up to
install software I don't want them to be able to just have it happen, I
want the password prompt to show up so that if they aren't me, or
weren't me that provided a password in the last 5 minutes, I don't want
them to be able to do it.
So on one hand you want to give your friend access to your *entire*
browser history / cookies etc. and on the other hand you will not give
them access to install packages from your already configured
Anyway, one criticism I've heard about this whole thing is that it's
"passwordless" and that's just not true unless you want it to be that
way. So the defaults for PackageKit in *mainline Fedora* should probably
pkgkit.update.signed.packages -> auth_admin_keep_always
- meaning you need to auth as root  and there's a fire-and-forget
"always remember this privilege" checkbox in the auth dialog)
pkgkit.update.unsigned.packages -> auth_admin
- meaning you need to auth as root, this privilege cannot be kept
pkgkit.install.signed.packages -> auth_admin_keep_always
- meaning you need to auth as yourself and there's a fire-and-forget
"always remember this privilege" checkbox)
pkgkit.install.unsigned.packages -> auth_admin
- meaning you need to auth as root, privilege cannot be kept.
This can be customized through /etc/PolicyKit/PolicyKit.conf. For
example, I envision we ship with this a configuration file that always
prevents the guest account from doing this. In addition, the desktop
spin will probably be passwordless for pkgkit.update.signed.packages or
whatever we decide - doing this is achieved simply by editing
PolicyKit.conf in the %post of the live cd creator. It's that simple
FWIW, any administrator can go in and change this as they see fit. For
example, I can add
to specify that all interactions with PackageKit always should ask for
the root password and that the privilege can't be retained. Or I can do
to specify that users davidz and jkeating can use PackageKit without
using a password and no one else can even attempt to auth for this. So
it's pretty flexible as you can see. See the man page for PolicyKit.conf
 : unless you configure PolicyKit to act as a sudo-ish system and
defines administrator authentication as "anyone from group wheel will