CheckboxPolicykit
|
Size: 4618
Comment: added notes from gobby and two design options
|
Size: 5586
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 8: | 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. | 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 12: | Line 12: |
| 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. | 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. |
| Line 14: | Line 14: |
| Ideally unless we are testing functionality that requires root permissions, then all tests should be performed as the current users. | Ideally unless we are testing functionality or performing actions that requires root permissions, then all tests should be performed as the current user. |
| Line 20: | 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. * 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). |
* 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 27: | Line 29: |
| * That PolicyKit is the right solution for this | * That Policy``Kit is the right solution for this |
| Line 29: | Line 31: |
| * That an appropriate workaround can be found for servers where Policy``Kit is not (currently) installed | |
| Line 32: | Line 35: |
| === Option 1: Always use PolicyKit when running checkbox === | === Option 1: Always use Policy``Kit when running checkbox === |
| Line 36: | Line 39: |
| === Option 2: Use PolicyKit for desktop cases === | === Option 2: Use Policy``Kit for desktop cases === |
| Line 41: | Line 44: |
| * Can Policy``Kit usage be implemented as a plugin? | === Option 3: Continue using `sudo` === If Policy``Kit is not viable, or will require too much effort to implement in the short term, then an alternative approach would be to extend the definition of tests to identify those that require elevated privileges, and use `sudo` to perform those actions. This would allow us to lower overall privileges, whilst still satisfying our use cases. However, this would be a temporary solution until Policy``Kit becomes viable for our needs. |
| Line 45: | Line 53: |
| ###This section should describe a plan of action (the "how") to implement the changes discussed. Could include subsections like: | * ''Can Policy``Kit usage be implemented as a plugin?'' -- Most likely. 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 49: | Line 63: |
| ##Should cover changes required to the UI, or specific UI that is required to implement this | Policy``Kit used to elevate the privilege of an individual test: |
| Line 51: | Line 65: |
| === Code Changes === | {{attachment:checkbox-policykit.png}} |
| Line 53: | Line 67: |
| ##Code changes should include an overview of what needs to change, and in some cases even the specific details. | For additional details, please see the CheckboxUI spec. |
| Line 57: | Line 71: |
| ##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. |
* Checkbox runs satisfactoryly without elevated privileges * Elevated privileges are requested for appropriate tests/actions |
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
That PolicyKit is the right solution for this
- That the current requirements for running as root only apply to a small number of tests
That an appropriate workaround can be found for servers where PolicyKit is not (currently) installed
Design
Option 1: Always use Policy``Kit when running checkbox
Requires investigation of a ConsoleKit+PolicyKit combination to elevate privileges selectively in the server and hardware certification cases
Option 2: Use Policy``Kit 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
Option 3: Continue using `sudo`
If PolicyKit is not viable, or will require too much effort to implement in the short term, then an alternative approach would be to extend the definition of tests to identify those that require elevated privileges, and use sudo to perform those actions.
This would allow us to lower overall privileges, whilst still satisfying our use cases. However, this would be a temporary solution until PolicyKit becomes viable for our needs.
Implementation
Can PolicyKit usage be implemented as a plugin? -- Most likely.
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
PolicyKit used to elevate the privilege of an individual test:
For additional details, please see the CheckboxUI spec.
Test/Demo Plan
- Checkbox runs satisfactoryly without elevated privileges
- Elevated privileges are requested for appropriate tests/actions
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
QATeam/Specs/CheckboxPolicykit (last edited 2009-01-19 15:32:50 by cpc4-oxfd8-0-0-cust39)