CheckboxPolicykit

Differences between revisions 2 and 3
Revision 2 as of 2008-12-08 19:39:56
Size: 3148
Editor: 216
Comment:
Revision 3 as of 2008-12-10 20:56:53
Size: 4618
Editor: cpc1-oxfd8-0-0-cust993
Comment: added notes from gobby and two design options
Deletions are marked like this. Additions are marked like this.
Line 9: Line 9:

== Release Note ==

No real user impact, so no release note necessary. Users will still be prompted for authentication, but at different times.
Line 26: Line 22:
 * On the server there is no X PolicyKit - either use an alternative
 * Some tests require packages to be installed. This should be initiated automatically by the test runner, but the user should have the power to accept or decline (and skip the test).
Line 34: Line 32:
##You can have subsections that better describe specific parts of the issue. === Option 1: Always use PolicyKit when running checkbox ===

 * Requires investigation of a Console``Kit+Policy``Kit combination to elevate privileges selectively in the server and hardware certification cases

=== Option 2: Use PolicyKit for desktop cases ===

 * Desktop automation, user-prompted testing and hardware profiling can all be performed usefully without root access
 * Elevating privileges optionally will enable more detailed hardware info collection and running of tests requiring root
 * Server tests and fully automated certification tests can be run from the command line with a {{{--run-as-root}}} flag
 * Can Policy``Kit usage be implemented as a plugin?
Line 60: Line 67:
##Use this section to take notes during the BoF; if you keep it in the approved spec, use it for summarising what was discussed and note any options that were rejected. Why are we running as root?
 * Information gathering
 * Debugging (apport)
 * Some test actions require sudo
 
Run as root and drop down to the user or escalate privileges to root when necessary?
 * run as a user and escalating when needed

On server side there is an issue with no X. Look into ConsoleKit

How do we deal with package installation?
 - Check ahead if some packages need to be installed, so the user experience is not too bad.
 * ask about installing a package in the beginning rather than asking in test 85 of 90
 
 Given that PolicyKit throws Authentication errors and refuses to unlock if dbus times out, I don't think it's likely to be pretty if there's no dbus at all
 - we would test for DBUS before trying to use PolicyKit
   - if DBUS isn't there, can it be forcibly started to prevent "scary" errors? (I'm not quite sure how this works) Or at least some sort of graceful degredation
  • Launchpad Entry: qa-checkbox-policykit

  • Created: 2008-12-05

  • Contributors: schwuk

  • Packages affected: checkbox

Summary

Checkbox currently runs completely as root which is not appropriate default behaviour for most end-user cases. Privileges should be elevated only when there is a specific need as defined in the test.

Rationale

Although running Checkbox through sudo has allowed us to work around permission related issues, this provides a "tainted" result as well as exposing the system vulnerabilites. In particular the latter will become more of a concern as we extend test coverage and incorporate community tests.

Ideally unless we are testing functionality that requires root permissions, then all tests should be performed as the current users.

This will also allow us to address current issues with integrating LDTP/desktop tests into Checkbox, as they cannot (easily) be run as root.

Use Cases

  • Jill desktop user starts Checkbox from the Admin menu (System Testing). She can get a basic view of her hardware and perform most tests without entering her password.
  • As we add more comprehensive desktop test coverage it is important that they run in an environment that is as realistic as possible - as a user, not as root.
  • On the server there is no X PolicyKit - either use an alternative

  • Some tests require packages to be installed. This should be initiated automatically by the test runner, but the user should have the power to accept or decline (and skip the test).

Assumptions

  • That PolicyKit is the right solution for this

  • That the current requirements for running as root only apply to a small number of tests

Design

Option 1: Always use PolicyKit when running checkbox

  • Requires investigation of a ConsoleKit+PolicyKit combination to elevate privileges selectively in the server and hardware certification cases

Option 2: Use PolicyKit for desktop cases

  • Desktop automation, user-prompted testing and hardware profiling can all be performed usefully without root access
  • Elevating privileges optionally will enable more detailed hardware info collection and running of tests requiring root
  • Server tests and fully automated certification tests can be run from the command line with a --run-as-root flag

  • Can PolicyKit usage be implemented as a plugin?

Implementation

UI Changes

Code Changes

Test/Demo Plan

Unresolved issues

BoF agenda and discussion

Why are we running as root?

  • Information gathering
  • Debugging (apport)
  • Some test actions require sudo

Run as root and drop down to the user or escalate privileges to root when necessary?

  • run as a user and escalating when needed

On server side there is an issue with no X. Look into ConsoleKit

How do we deal with package installation?

  • - Check ahead if some packages need to be installed, so the user experience is not too bad.
  • ask about installing a package in the beginning rather than asking in test 85 of 90

    Given that PolicyKit throws Authentication errors and refuses to unlock if dbus times out, I don't think it's likely to be pretty if there's no dbus at all - we would test for DBUS before trying to use PolicyKit

    • - if DBUS isn't there, can it be forcibly started to prevent "scary" errors? (I'm not quite sure how this works) Or at least some sort of graceful degredation


CategorySpec

QATeam/Specs/CheckboxPolicykit (last edited 2009-01-19 15:32:50 by cpc4-oxfd8-0-0-cust39)