h1. FSFVMRootAccess

h2. Root password

The root password is managed by the FSF: the FSF sysadmins have access to it and it's stored encrypted somewhere.

If the VM doesn't show up on the network, they still need to be able to bring it back up by logging in and configuring the network manually.

In any case, if the VM doesn't boot or doesn't show up on the network they are able to get access to it without password by booting it with the following command line:
<pre>init=/bin/sh</pre>

However using chroot (which also works when the VM is booted) from the host doesn't work here: if a VM is compromised somehow, chrooting into it could also compromise the host: when chrooting as root, the code and commands from within the VM are executed as root.

h2. SSH Root access

The FSF sysadmins also have root access to the VM as they might need to access the VM through the network for various reasons like to shut it down cleanly in case of serious issues (security risk to the network), do emergency fixes inside it, test if SSH works, and so on.

When adding people to the authorized_keys:
* We need the agreement of at least one person that is not you and that is from the Replicant steering commitee
* We need to add it in the "List of people having access":https://redmine.replicant.us/projects/replicant-infrastructure/wiki/NetworkInfrastructure#Network-Infrastructure so we have to make the person is also ok for being mentioned as a pre-requisite for giving that person access.
* We also have to inform the FSF sysadmins about it as they also maintain a list of people that have access to VMs on their side (along with contact information for at least a subset of the people for emergency purposes).
* They probably have an agreement to agree to for new people as well (which has clauses about good practices like to not give access to anybody like that, what the FSF staff can do if the VM is compromised, etc).