Ubuntu Wiki

• 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

PolicyKit used to elevate the privilege of an individual test:

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