diff --git a/server/README.md b/server/README.md index 67d1787..2285cee 100644 --- a/server/README.md +++ b/server/README.md @@ -17,13 +17,11 @@ We only keep the basic user journey working. ## What we keep working - The prompt: `root@khaos-im-kiez:~#`, which `~/.zshrc` sets. -- The home directory the user ends up in: `/home/root`. It is the one from the `root` entry in `/etc/passwd`, - which the user cannot change, because `/etc` is read-only for them. They can delete their home directory, though. +- The home directory the user ends up in: `/home/root`. They can delete it, but not change where it is. - `cat README`, `cat README.en`, `cat CODE_OF_CONDUCT` and `cat CODE_OF_CONDUCT.en` always work. The four files are always there and always regular text files. - The website can log in: the key it uses is in `~/.ssh/authorized_keys`. That key gets access to the `root` user - only, never to the Administrator account. The keys of the people who deploy - their own key, not the key of the - website - are in the authorized_keys of both accounts. + only, never to the Administrator account. Modifying the four files is allowed; the next cleanup undoes it. Deleting them is not permanent either. @@ -36,36 +34,25 @@ stop them from that - but the next cleanup brings it back. Until then, the site Everything else. If the user breaks the shell, the packages, the disk or the connection, we fix that by hand or throw the box away. The cleanup does not try. -Two things that the user cannot break and therefore do not need to be restored: the entry in `/etc/passwd` with -the home directory and the shell, and the host keys in `/etc/ssh`, which the website pins. The sshd runs as SYSTEM, -so the user cannot restart it with a different key either. +Two things that the user cannot break: the entry in `/etc/passwd` with the home directory and the shell, because +`/etc` is read-only for them, and the host keys in `/etc/ssh`, which the website pins. The sshd runs as SYSTEM, so +the user cannot restart it with a different key either. ## The cleanup The scheduled task `KiK restore shell files` runs every 30 minutes and at every startup, as SYSTEM. The user cannot stop it: the task, its script and the copies it restores from are readable and writable only by SYSTEM and the -administrators. +administrators. Neither the setup nor the cleanup ever runs as the `root` user. -Neither the setup nor the cleanup ever runs as the `root` user. The setup runs in an elevated PowerShell, as an -administrator, and refuses to run without those rights; the cleanup runs as SYSTEM. The `root` account is a -different one, without administrator rights, and it never executes any of it. - -What the cleanup does: - -1. Creates `/home/root` if it is gone, and gives the `root` account write access on it. -2. Puts every copy in `files/` back into the home directory: the shell configuration, the keys and the four text - files. - -Anything that is not a regular file - a directory or a link - is removed and replaced by the copy, so that the -files cannot become anything but text. The contents are restored as well: the user may edit the files, the next run -undoes that. +It creates `/home/root` if it is gone, and puts the copies from `C:\ProgramData\kik-restore\files` back into the +home directory: the shell configuration, the keys and the four text files. Anything that is not a regular file is +replaced, so that the files cannot become anything but text. ## This directory - `resources/` - everything that goes to the server: `home/` for the home directory of the root user - `~/.zshrc`, `~/.zshenv`, the keys in `~/.ssh/authorized_keys` and the four text files - and `admin/` for the home directory - of the Administrator, which holds the keys of the people who deploy. The key of the website is not among them and - never gets administrator rights. + of the Administrator, which holds the keys of the people who deploy. - `scripts/make_files.py` - builds the four text files. - `scripts/deploy.sh` - deploys the cleanup to the server and installs it. - `scripts/install_restore_task.ps1` - installs the scheduled task. @@ -79,18 +66,13 @@ The four text files are built from the website's pages, the other files in the r server/scripts/deploy.sh The script logs in as `Administrator` - whose shell is a Windows one - copies the scripts and the resources to the -Administrator's home directory and runs the installer there. It logs in with the personal key of the deployer, from -the agent or from `-i`; the key of the website never gets administrator rights, it only logs in as the root user. -It checks the host key against the one the website pins, and that the key of the website is the first one in -`resources/home/.ssh/authorized_keys`. `--uninstall` removes the task again. +Administrator's home directory and runs the installer there, with the personal key of the deployer. The key of the +website never gets administrator rights. `--uninstall` removes the task again. The installer can also be run by hand, in an elevated PowerShell on the server: powershell -ExecutionPolicy Bypass -File .\scripts\install_restore_task.ps1 -The task runs as SYSTEM, so the `root` user can neither stop it nor change the copies it restores from. It also -runs at startup. Remove it again with `-Uninstall`. - ## Getting the SSH access back If the home directory was deleted, the key that lets the website in went with it. The cleanup puts it back by