CheckboxPolicykit

Differences between revisions 1 and 6 (spanning 5 versions)
Revision 1 as of 2008-12-05 11:50:12
Size: 2851
Editor: cpc1-oxfd8-0-0-cust993
Comment: new spec
Revision 6 as of 2009-01-19 15:32:50
Size: 4758
Editor: cpc4-oxfd8-0-0-cust39
Comment:
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
Line 9: Line 8:
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.

== Release Note ==

##This section should include a paragraph describing the end-user impact of this change. It is meant to be included in the release notes of the first release in which it is implemented. (Not all of these will actually be included in the release notes, at the release manager's discretion; but writing them is a useful exercise.)
Checkbox currently runs completely as root which is not appropriate default behaviour for most end-user cases. Ideally privileges should be elevated only where there is a specific need as defined in the test.
Line 17: Line 12:
When running Checkbox on an end-user desktop it is more appropriate to elevate privileges selectively. Desktop tests running with LDTP should run as a user and Checkbox should be able to run in the same mode. Although running Checkbox through sudo has allowed us to work around permission related issues, this provides a "tainted" result as well as potentially exposing system vulnerabilities. The latter in particular will become more of a concern as we extend test coverage and incorporate community tests.

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

This will also allow us to address current issues with integrating LDTP/desktop tests into Checkbox, as they cannot (easily) be run as root.
Line 21: Line 20:
 * 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.
 * Jill starts Checkbox from the Admin menu (System Testing). She can get a basic view of her hardware and perform most tests '''as herself''' without entering her password
 * Simon runs a test that queries device information which requires root access. He is asked for his password to allow access to that information
 * Emma runs a new test that requires additional packages to be installed. She is asked for her password to install those packages automatically
  * 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).
 * Bill is running a suite of PostgreSQL tests that need to be run as the `postgres` user. He is prompted for his password to allow this to happen
 * 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
Line 26: Line 29:
 * The tests that still require root to run can be run in a different mode
Line 28: Line 33:
##You can have subsections that better describe specific parts of the issue.  * Run checkbox as a regular user by default
 * Add a command-line parameter run checkbox in root mode
  * e.g. {{{sudo checkbox --root}}}
  * This mode will be used when policykit is not installed (server) and for certification testing
 * Test definitions will be extended to contain a ''needs-root'' flag which will prompt the user for a password when testing starts using policy-kit
  * Checkbox will check for the availability of policy-kit on start and if a test requiring elevated priveliges is scheduled it will exit with an error
 * Package installation is out of scope for the current spec. If a prerequisite for the test is not met the user should be notified and referred to the standard packaging tool.
  * In root mode this can be worked around by making the test install the package directly, eliminating the need for user-interaction.
Line 32: Line 44:
###This section should describe a plan of action (the "how") to implement the changes discussed. Could include subsections like: Since there may be multiple, differing requests to elevate privileges in a single test session, individual tests should be evaluated early in the Checkbox process and authorisation step performed as a single action for all requirements.

This authorisation step needs to be performed immediately prior to tests being run.

If authorisation is declined or unsuccessful, the relevant tests should be skipped with an appropriate, informative comment.
Line 36: Line 52:
##Should cover changes required to the UI, or specific UI that is required to implement this

=== Code Changes ===

##Code changes should include an overview of what needs to change, and in some cases even the specific details.
Please see the CheckboxUI spec.
Line 44: Line 56:
##It's important that we are able to test new features, and demonstrate them to users. Use this section to describe a short plan that anybody can follow that demonstrates the feature is working. This can then be used during testing, and to show off after release. Please add an entry to http://testcases.qa.ubuntu.com/Coverage/NewFeatures for tracking test coverage.

##This need not be added or completed until the specification is nearing beta.

== Unresolved issues ==

##This should highlight any issues that should be addressed in further specifications, and not problems with the specification itself; since any specification with problems cannot be approved.
 * Checkbox runs satisfactoryly without elevated privileges
 * Checkbox runs satisfactoryly in root mode
 * Elevated privileges are requested for appropriate tests/actions
Line 54: Line 62:
##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. Ideally privileges should be elevated only where 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 potentially exposing system vulnerabilities. The latter in particular will become more of a concern as we extend test coverage and incorporate community tests.

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

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 starts Checkbox from the Admin menu (System Testing). She can get a basic view of her hardware and perform most tests as herself without entering her password

  • Simon runs a test that queries device information which requires root access. He is asked for his password to allow access to that information
  • Emma runs a new test that requires additional packages to be installed. She is asked for her password to install those packages automatically
    • 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).
  • Bill is running a suite of PostgreSQL tests that need to be run as the postgres user. He is prompted for his password to allow this to happen

  • 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

Assumptions

  • The tests that still require root to run can be run in a different mode

Design

  • Run checkbox as a regular user by default
  • Add a command-line parameter run checkbox in root mode
    • e.g. sudo checkbox --root

    • This mode will be used when policykit is not installed (server) and for certification testing
  • Test definitions will be extended to contain a needs-root flag which will prompt the user for a password when testing starts using policy-kit

    • Checkbox will check for the availability of policy-kit on start and if a test requiring elevated priveliges is scheduled it will exit with an error
  • Package installation is out of scope for the current spec. If a prerequisite for the test is not met the user should be notified and referred to the standard packaging tool.
    • In root mode this can be worked around by making the test install the package directly, eliminating the need for user-interaction.

Implementation

Since there may be multiple, differing requests to elevate privileges in a single test session, individual tests should be evaluated early in the Checkbox process and authorisation step performed as a single action for all requirements.

This authorisation step needs to be performed immediately prior to tests being run.

If authorisation is declined or unsuccessful, the relevant tests should be skipped with an appropriate, informative comment.

UI Changes

Please see the CheckboxUI spec.

Test/Demo Plan

  • Checkbox runs satisfactoryly without elevated privileges
  • Checkbox runs satisfactoryly in root mode
  • Elevated privileges are requested for appropriate tests/actions

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)