added notes from gobby and two design options
|Deletions are marked like this.||Additions are marked like this.|
|Line 27:||Line 27:|
|* That PolicyKit is the right solution for this||* That Policy``Kit is the right solution for this|
|Line 49:||Line 49:|
|##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:
Launchpad Entry: qa-checkbox-policykit
Packages affected: checkbox
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.
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.
- 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).
That PolicyKit is the right solution for this
- That the current requirements for running as root only apply to a small number of tests
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?
PolicyKit used to elevate the privilege of an individual test:
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