If he is the (super)admin then he should be able to start the service himself.
What can you do with admin mode that requires root. Only upgrade packages?
Does not really show a difference in the description between admin and superadmin mode. Both say “for software installation” but when should you choose admin or superadmin?
Any ordinary administration tasks e.g. editing config files.
Admin is still restricted under the default apparmor policy. Superadmin (or superroot) has its own, more permissive policy.
Currently, it just has access to sysctls and doesn’t include the dangerous-files abstraction.
I am copying over the conceptual notes to a wiki page and refining the concept. Please check:
What would probably cause chaos is to have sometimes 1 word and sometimes 2 words.
also
“But I used root.” “You need super root.” “I mean, I used super root.”
Therefore I think single words should be avoided. Documentation should introduce and consistently use two words. Which ones?
But limited not sound good. What about “daily admin”? Also not good, because we already say user “user” is for daily activities. The word needs to be more encouraging, positive than “limited” but less exiting than “daily”. What about “normal admin”, “normal root”? Not good because “normal”, the norm, what most do is trusted root by default. Also word “untrusted” in “untrusted admin” seems confusing.
Any better suggestions thans limited admin / limited root?
restricted admin /restricted root ?
HulaHoop via Whonix Forum:
restricted admin /restricted root ?
Technically correct but sounds so negative, sounds so not worth
bothering with. Maybe there’s no better alternative. Let’s see. Other ideas?
Secure admin / secure root?
Using that for now until/if there are better suggestions.
Secure is also not too great since that somewhat suggests “secure, use
all the time”.
how about inert or neutral root?
One thing hasn’t been considered yet at all: server support. grub boot menu isn’t easily accessible for many/most servers. How would these various boot modes be available for servers?
Live mode: that probably makes little sense on servers.
Persistent user / secureadmin / superadmin however might make sense?
Even if the webapp (ruining as non-root, user) this is catastrophic but if breaking out from a VM to the host is avoided (thanks to restricted root), that’s very worthwhile. Any way to let servers securely toggle these boot options?
This is a deal breaker for installation by default.
(At least as long there’s no different meta packages for desktop use case and server use case. And that I would like to avoid for simplicity. Better solving server support.)
Question, does “PERSISTENT mode USER” allow for a separate partitioned FDE storage of the persistent data, that would otherwise be independent and inaccessible from a partition loaded under “LIVE mode USER”
If so, is there any documentation outlining how to do this?
Thanks in advance I look forward to using Whonix
No. That would be far more complex that the current design.
Not that I am aware. Also Self Support First Policy for Whonix applies.