low-hanging fruit

[David Zeuthen]

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 the user
> 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.  

> If a
> 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
repositories?

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
be

 pkgkit.update.signed.packages  ->  auth_admin_keep_always
   - meaning you need to auth as root [1] 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
really.

FWIW, any administrator can go in and change this as they see fit. For
example, I can add

 <match action="pkgkit.*">
   <return result="auth_admin"/>
 </match>

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
this

 <match action="pkgkit.*">
   <match user="davidz|jkeating">
     <return result="yes"/>
   </match>
   <return result="no"/>
 </match>

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
for details.

       David

[1] : unless you configure PolicyKit to act as a sudo-ish system and
defines administrator authentication as "anyone from group wheel will
do".