Feature: unlocking privileged operations
Allow standard sessions sign-ins to perform privileged actions.
Phillip J. Fry is a junior sysadmin at his company who signs into his servers remotely with a Web browser. Usually, he only checks the status on servers, but once in a while, he needs to do perform tasks that require additional privileges.
Phillip signs into Cockpit, without checking the box to "Reuse my password for privileged tasks", as he's planning on checking the system status quickly. While signed in, he notices a problem with resource usage and, rather than spending hours debugging the problem, decides to reboot the server for a quick fix.
Signing out and signing back in with privileges, especially across several servers, is arduous, so Phillip is happy Cockpit lets him quickly gain rights to reboot the server.
- Sign in as a standard user
- Perform an action to escalate privilege
- Pass credential check (usually in the form of a password prompt)
- Accomplish system task that requires administrator privileges
- (Optional) Accomplish additional system tasks
- (Optional) De-escalate privilege
- Only needed when signed-in without privileged operations checked
- Do we want to remove the sign-in checkbox from the sign-in page and always have escalation status (such as in the top-right)?
- It may make sense to move the checkbox from the sign-in page to a saved user-pref for those who do not have NOPASSWD rights (which would prompt when enabling)
The following are the different ways to handle privellaged information and actions within Cockpit. We should evaluate what makes sense on a case-by-case basis, but opt for a consistent default.
- Hide non-admin actions
- Advantage: For those signed in to view normal-user-only, they'd never see something they cannot interact with.
- Disadvantage: UI elements and locations shift depending on if someone has simple rights versus admin rights
- Have admin-only items displayed, but disabled
- Advantage: UI consistency, even if some items cannot be manipulated
- Disadvantage: One would have to unlock before performing actions
- Hybrid Placeholders
- Actual items could be hidden, with a simplified version displayed
- Has the advantages of both #1 & #2 (but still the disadvantage of #2)
Depending on the UI in Cockpit, I would suggest displaying a less featureful version of UI when appropriate (#2), or at least show a placeholder with relevant information (#3). I would suggest not hiding information as the disadvantages are too severe (#1).
It may get a bit trickier with some features within Cockpit, however. Example: The tuned-based performance mode is not displayed properly when in a restricted session. What label can be used for it, if it is not possible to know what mode tuned is in without administration privilege?
- Global Unlock / Lock button & status
- In the top-right of Cockpit, next to the dropdown
- Alternatively, inside the dropdown itself (although it would be buried)
- Not visible when signed in with the privileged checkbox on the sign-in screen
- Disabled UI when not signed in should have a contextual way to trigger the escalation prompt
- In some cases, the entire widget could be selectable, but text should probably be selectable
- There could be a local unlock icon (but this would be redundant)
- For things that do have action buttons, the escalation prompt can display after performing the action
- However, this has the issue of not knowing if one would get the prompt or not when clicking on any action (making it feel like a game of chance)
- An escalation prompt
- Password
- Would a non-password authentication method be used? (2FA, Kerberos, etc.)
- Would the auth be saved for the session, or should there be a one-off mode?
- (I would suggest the auth being saved for the session, which is currently the behavior when signing in with the sign-in page auth checkbox.)
- Do not re-display when switching from unlocked to locked to unlocked, if saved for the session.
WIP
This mockup shows a minor modification to allow unlock access for Docker by authenticating. It is possible to unlock in the top-right before accessing the Docker page. Also, unlocking in the top right should automatically resolve the access rights to affected components (the Docker page being the example here).
It's only a simple password prompt right now. There is no "remember" checkbox, as it should switch to admin privileges once per session, until everything is (optionally) manually locked in the top-right of Cockpit.
Note: The password entry should be automatically focused (despite the mockup not currently showing this yet). Enter should submit the password and hitting escape should be mapped to cancel. The × to close the dialog should also be mapped to cancel.
As this affects multiple parts of Cockpit, more examples will be coming soon.
