forge
/
archive_hook.sh
Archived
1
0
Fork 0
Code Issues 4 Pull Requests Releases Wiki Activity

Update README with latest developments

This commit is contained in:
southerntofu 2020-04-26 23:01:11 +02:00
parent 7dfb1012b4
commit cbe59d905b
1 changed files with 14 additions and 14 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

28
README.md
View File

@ -64,23 +64,18 @@ Additionally, for each user `$u` owning one or more repositories, there would be
## webhook (wrapper script)
Because of how the system is designed, the `webhook` script needs to run as user `webhook` (as this user owns the database) but the script needs to reliably know which user called it. To run as `webhook` user, we simply set the suid bit on `/usr/local/bin/webhook` (owned by `webhook:webhook`) with `chmod u+s /usr/local/bin/webhook`.
Because of how the system is designed, the `webhook` script needs to run as user `webhook` (as this user owns the database) but the script needs to reliably know which user called it. To run as `webhook` user, we simply rely on sudo with the following `/etc/sudoers` rules:
**Note**: We cannot rely on uid/ruid to provide accurate information on the user calling the script, because a simple `setresuid()` (~> `man 2 setresuid`) call would allow anyone to impersonate the `webhook` user.
```
* ALL=(webhook:webhook) NOPASSWD: /usr/local/bin/webhook-backend
* webhook ALL=(root:root) NOPASSWD: /usr/local/bin/webhook-run
```
So, in fact, `webhook` would be a simple wrapper script for `webhook-backend`, which would be the setuid script. This `webhook` script would:
1. Create a file `~/.webhook.LOCK` with the current arguments (`$@`)
2. Call `webhook-backend` with the current arguments
3. Remove `~/.webhook.LOCK`
**Note**: A such architecture makes the system strongly synchronous. As such, it would not support running multiple commands at the same time for a single user, which i do not believe to be a problem.
So, in fact, `webhook` would be a simple wrapper script for `webhook-backend`.
## webhook-backend
The backend script, running as user `webhook`, will check whether the declared ruid (real user id) has a `~/.webhook.LOCK` file containing the same arguments it just received. This will prevent user impersonation.
If the check succeeds, `webhook-backend` processes the arguments. The first argument is the command, and can be one of the following: `list`, `add`, `remove`, `subscribe`, `unsubscribe`, `secret`. If no argument is supplied, the `list` command is implied.
`webhook-backend` has a first command argument, which can be one of the following: `list`, `add`, `remove`, `subscribe`, `unsubscribe`, `secret`. If no argument is supplied, the `list` command is implied.
Some commands take a remote argument, and some take secret arguments. The remote is abbreviated `$r`, and the secret `$s`. Additionally, `$rhex` designates `$r` hex-encoded. `$u` is the real user running the script.
@ -100,8 +95,13 @@ For each remote found for the user, the `list` command prints with tab separatio
2. Print `$r`
3. If `.$rhex.owner` does not contain `$u`, continue
4. Print `\t` plus the contents of `.$rhex.secret`
5. If `owned-by/$u/$rhex` exists, print `\tx`.
6. Print a newline `\n`
5. Print a newline
Additionally, for each file `$f` in owned-by/$u:
1. If `$rhex.$u` exists, do nothing because the user is still subscribed
2. Read the secret `$s` from `.$rhex.secret`
2. Print `$r\t\$s\tx` plus a newline
### add