Fossil SCM
Investigated the use of HTTP for sync over ssh:// and file:// URLs and added what I found to the "Caps Affect Web Interfaces Only" section of the new caps docs.
Commit
845b45943991862bb25be780987bc9a38db117f71274a745cead14d98cf444b9
Parent
4671ddb17966a6e…
1 file changed
+34
-15
+34
-15
| --- www/caps/index.md | ||
| +++ www/caps/index.md | ||
| @@ -44,11 +44,11 @@ | ||
| 44 | 44 | When a user visits a [served Fossil repository][svr] via its web UI, |
| 45 | 45 | they initially get the capabilities of the “nobody” user category. This |
| 46 | 46 | category would be better named “everybody” because it applies whether |
| 47 | 47 | you’re logged in or not. |
| 48 | 48 | |
| 49 | -When a user logs in as “anonymous” via [`/login`](/help?cmd=/login) they | |
| 49 | +When a user logs in as “anonymous” via [`/login`](/help?name=/login) they | |
| 50 | 50 | get all of the “nobody” category’s caps plus those assigned to the |
| 51 | 51 | “anonymous” user category. It would be better named “user” because it |
| 52 | 52 | affects all logged-in users, not just those logged in via Fossil’s |
| 53 | 53 | anonymous user feature. |
| 54 | 54 | |
| @@ -195,13 +195,13 @@ | ||
| 195 | 195 | that, you want to deny **Clone** capability instead. |
| 196 | 196 | |
| 197 | 197 | Withholding the **Read** capability has a different effect: it |
| 198 | 198 | prevents a web client from viewing [embedded |
| 199 | 199 | documentation][edoc], using [the file |
| 200 | -browser](/help?cmd=/dir), and pulling file content via the | |
| 201 | -[`/artifact`](/help?cmd=/artifact), [`/file`](/help?cmd=/file), and | |
| 202 | -[`/raw`](/help?cmd=/raw) URLs. | |
| 200 | +browser](/help?name=/dir), and pulling file content via the | |
| 201 | +[`/artifact`](/help?name=/artifact), [`/file`](/help?name=/file), and | |
| 202 | +[`/raw`](/help?name=/raw) URLs. | |
| 203 | 203 | It is is common to withhold **Read** capability from low-status visitors |
| 204 | 204 | on private or semi-private repos to prevent them from pulling individual |
| 205 | 205 | elements of the repo over the web one at a time, as someone may do when |
| 206 | 206 | denied the bulk **Clone** capability. |
| 207 | 207 | |
| @@ -228,11 +228,11 @@ | ||
| 228 | 228 | incorrect name from Fossil reports, but the original values remain in |
| 229 | 229 | the repository [forever][shun]. It is [difficult enough][fos] to fix |
| 230 | 230 | such problems automatically during sync that we are unlikely to ever do |
| 231 | 231 | so. |
| 232 | 232 | |
| 233 | -[auo]: /help?cmd=new | |
| 233 | +[auo]: /help?name=new | |
| 234 | 234 | [fos]: ./impl.md#filter |
| 235 | 235 | [shun]: ../shunning.wiki |
| 236 | 236 | |
| 237 | 237 | |
| 238 | 238 | |
| @@ -265,26 +265,45 @@ | ||
| 265 | 265 | `file://` URL or a file system path. This should strike you as sensible: |
| 266 | 266 | only local file permissions matter when operating on a local SQLite DB |
| 267 | 267 | file. The same is true when working on a clone done over such a path, |
| 268 | 268 | except that there are then two sets of file system permission checks: |
| 269 | 269 | once to modify the working check-out’s repo clone DB file, then again on |
| 270 | -[sync][sync] with the parent DB file. | |
| 270 | +[sync][sync] with the parent DB file. The Fossil capability checks are | |
| 271 | +effectively defeated because your user has [**Setup**][s] capability on | |
| 272 | +both sides of the sync. | |
| 271 | 273 | |
| 272 | 274 | What may surprise you is that user caps *also do not affect SSH!* When |
| 273 | 275 | you make a change to such a repository, the change first goes to the |
| 274 | 276 | local clone, where file system permissions are all that matter, but then |
| 275 | 277 | upon sync, the situation is effectively the same as when the parent repo |
| 276 | 278 | is on the local file system. If you can log into the remote system over |
| 277 | 279 | SSH and that user has the necessary file system permissions on that |
| 278 | -remote repo DB file, your user is effectively the [all-powerful Setup | |
| 279 | -user][apsu] on both sides of the SSH connection. | |
| 280 | - | |
| 281 | -Fossil reuses the HTTP-based [sync protocol][sp] in both cases above, | |
| 282 | -tunnelling HTTP through an OS pipe or through SSH (FIXME?), but because | |
| 283 | -the checks for capabilities like [**Read**][o] and [**Write**][i] are | |
| 284 | -done against your effective Setup user on the other repo, the check only | |
| 285 | -has an effect when done over an `http[s]://` URL. | |
| 280 | +remote repo DB file, it is the same situation as for `file://` URLs. | |
| 281 | + | |
| 282 | +All Fossil syncs are done over HTTP, even for `file://` and `ssh://` | |
| 283 | +URLs: | |
| 284 | + | |
| 285 | +* For `ssh://` URLs, Fossil pipes the HTTP conversation through a | |
| 286 | + local SSH client to a remote instance of Fossil running the | |
| 287 | + [`test-http`](/help?name=test-http) command to recieve the tunneled | |
| 288 | + HTTP connection without cap checks. The SSH client defaults to “`ssh | |
| 289 | + -e none -T`” on most platforms, except on Windows where it defaults | |
| 290 | + to “`plink -ssh -T`”. You can override this with [the `ssh-command` | |
| 291 | + setting](/help?name=ssh-command). | |
| 292 | + | |
| 293 | +* For `file://` URLs, the “sending” Fossil instance writes its side of | |
| 294 | + the HTTP conversation out to a temporary file in the same directory | |
| 295 | + as the local repo clone and then calls itself on the “receiving” | |
| 296 | + repository to read that same HTTP transcript file back in to apply | |
| 297 | + those changes to that repository. Presumably Fossil doesn’t do this | |
| 298 | + with a pipe to ease portability to Windows. | |
| 299 | + | |
| 300 | +Because both mechanisms work on local repos, the checks for capabilities | |
| 301 | +like [**Read**][o] and [**Write**][i] within the HTTP conversation for | |
| 302 | +such URLs can never return “false,” because you are the [**Setup**][s] | |
| 303 | +user on both sides of the conversation. Such checks only have a useful | |
| 304 | +effect when done over an `http[s]://` URL. | |
| 286 | 305 | |
| 287 | 306 | |
| 288 | 307 | ## <a name="pubpg"></a>Public Pages |
| 289 | 308 | |
| 290 | 309 | In Admin → Access, there is an option for giving a list of [globs][glob] |
| @@ -349,7 +368,7 @@ | ||
| 349 | 368 | [7]: ./ref.html#7 |
| 350 | 369 | |
| 351 | 370 | [glob]: https://en.wikipedia.org/wiki/Glob_(programming) |
| 352 | 371 | [japi]: https://docs.google.com/document/d/1fXViveNhDbiXgCuE7QDXQOKeFzf2qNUkBEgiUvoqFN4/view#heading=h.6k0k5plm18p1 |
| 353 | 372 | [sp]: ../sync.wiki |
| 354 | -[sync]: /help?cmd=sync | |
| 373 | +[sync]: /help?name=sync | |
| 355 | 374 | [wp]: /help#webpages |
| 356 | 375 |
| --- www/caps/index.md | |
| +++ www/caps/index.md | |
| @@ -44,11 +44,11 @@ | |
| 44 | When a user visits a [served Fossil repository][svr] via its web UI, |
| 45 | they initially get the capabilities of the “nobody” user category. This |
| 46 | category would be better named “everybody” because it applies whether |
| 47 | you’re logged in or not. |
| 48 | |
| 49 | When a user logs in as “anonymous” via [`/login`](/help?cmd=/login) they |
| 50 | get all of the “nobody” category’s caps plus those assigned to the |
| 51 | “anonymous” user category. It would be better named “user” because it |
| 52 | affects all logged-in users, not just those logged in via Fossil’s |
| 53 | anonymous user feature. |
| 54 | |
| @@ -195,13 +195,13 @@ | |
| 195 | that, you want to deny **Clone** capability instead. |
| 196 | |
| 197 | Withholding the **Read** capability has a different effect: it |
| 198 | prevents a web client from viewing [embedded |
| 199 | documentation][edoc], using [the file |
| 200 | browser](/help?cmd=/dir), and pulling file content via the |
| 201 | [`/artifact`](/help?cmd=/artifact), [`/file`](/help?cmd=/file), and |
| 202 | [`/raw`](/help?cmd=/raw) URLs. |
| 203 | It is is common to withhold **Read** capability from low-status visitors |
| 204 | on private or semi-private repos to prevent them from pulling individual |
| 205 | elements of the repo over the web one at a time, as someone may do when |
| 206 | denied the bulk **Clone** capability. |
| 207 | |
| @@ -228,11 +228,11 @@ | |
| 228 | incorrect name from Fossil reports, but the original values remain in |
| 229 | the repository [forever][shun]. It is [difficult enough][fos] to fix |
| 230 | such problems automatically during sync that we are unlikely to ever do |
| 231 | so. |
| 232 | |
| 233 | [auo]: /help?cmd=new |
| 234 | [fos]: ./impl.md#filter |
| 235 | [shun]: ../shunning.wiki |
| 236 | |
| 237 | |
| 238 | |
| @@ -265,26 +265,45 @@ | |
| 265 | `file://` URL or a file system path. This should strike you as sensible: |
| 266 | only local file permissions matter when operating on a local SQLite DB |
| 267 | file. The same is true when working on a clone done over such a path, |
| 268 | except that there are then two sets of file system permission checks: |
| 269 | once to modify the working check-out’s repo clone DB file, then again on |
| 270 | [sync][sync] with the parent DB file. |
| 271 | |
| 272 | What may surprise you is that user caps *also do not affect SSH!* When |
| 273 | you make a change to such a repository, the change first goes to the |
| 274 | local clone, where file system permissions are all that matter, but then |
| 275 | upon sync, the situation is effectively the same as when the parent repo |
| 276 | is on the local file system. If you can log into the remote system over |
| 277 | SSH and that user has the necessary file system permissions on that |
| 278 | remote repo DB file, your user is effectively the [all-powerful Setup |
| 279 | user][apsu] on both sides of the SSH connection. |
| 280 | |
| 281 | Fossil reuses the HTTP-based [sync protocol][sp] in both cases above, |
| 282 | tunnelling HTTP through an OS pipe or through SSH (FIXME?), but because |
| 283 | the checks for capabilities like [**Read**][o] and [**Write**][i] are |
| 284 | done against your effective Setup user on the other repo, the check only |
| 285 | has an effect when done over an `http[s]://` URL. |
| 286 | |
| 287 | |
| 288 | ## <a name="pubpg"></a>Public Pages |
| 289 | |
| 290 | In Admin → Access, there is an option for giving a list of [globs][glob] |
| @@ -349,7 +368,7 @@ | |
| 349 | [7]: ./ref.html#7 |
| 350 | |
| 351 | [glob]: https://en.wikipedia.org/wiki/Glob_(programming) |
| 352 | [japi]: https://docs.google.com/document/d/1fXViveNhDbiXgCuE7QDXQOKeFzf2qNUkBEgiUvoqFN4/view#heading=h.6k0k5plm18p1 |
| 353 | [sp]: ../sync.wiki |
| 354 | [sync]: /help?cmd=sync |
| 355 | [wp]: /help#webpages |
| 356 |
| --- www/caps/index.md | |
| +++ www/caps/index.md | |
| @@ -44,11 +44,11 @@ | |
| 44 | When a user visits a [served Fossil repository][svr] via its web UI, |
| 45 | they initially get the capabilities of the “nobody” user category. This |
| 46 | category would be better named “everybody” because it applies whether |
| 47 | you’re logged in or not. |
| 48 | |
| 49 | When a user logs in as “anonymous” via [`/login`](/help?name=/login) they |
| 50 | get all of the “nobody” category’s caps plus those assigned to the |
| 51 | “anonymous” user category. It would be better named “user” because it |
| 52 | affects all logged-in users, not just those logged in via Fossil’s |
| 53 | anonymous user feature. |
| 54 | |
| @@ -195,13 +195,13 @@ | |
| 195 | that, you want to deny **Clone** capability instead. |
| 196 | |
| 197 | Withholding the **Read** capability has a different effect: it |
| 198 | prevents a web client from viewing [embedded |
| 199 | documentation][edoc], using [the file |
| 200 | browser](/help?name=/dir), and pulling file content via the |
| 201 | [`/artifact`](/help?name=/artifact), [`/file`](/help?name=/file), and |
| 202 | [`/raw`](/help?name=/raw) URLs. |
| 203 | It is is common to withhold **Read** capability from low-status visitors |
| 204 | on private or semi-private repos to prevent them from pulling individual |
| 205 | elements of the repo over the web one at a time, as someone may do when |
| 206 | denied the bulk **Clone** capability. |
| 207 | |
| @@ -228,11 +228,11 @@ | |
| 228 | incorrect name from Fossil reports, but the original values remain in |
| 229 | the repository [forever][shun]. It is [difficult enough][fos] to fix |
| 230 | such problems automatically during sync that we are unlikely to ever do |
| 231 | so. |
| 232 | |
| 233 | [auo]: /help?name=new |
| 234 | [fos]: ./impl.md#filter |
| 235 | [shun]: ../shunning.wiki |
| 236 | |
| 237 | |
| 238 | |
| @@ -265,26 +265,45 @@ | |
| 265 | `file://` URL or a file system path. This should strike you as sensible: |
| 266 | only local file permissions matter when operating on a local SQLite DB |
| 267 | file. The same is true when working on a clone done over such a path, |
| 268 | except that there are then two sets of file system permission checks: |
| 269 | once to modify the working check-out’s repo clone DB file, then again on |
| 270 | [sync][sync] with the parent DB file. The Fossil capability checks are |
| 271 | effectively defeated because your user has [**Setup**][s] capability on |
| 272 | both sides of the sync. |
| 273 | |
| 274 | What may surprise you is that user caps *also do not affect SSH!* When |
| 275 | you make a change to such a repository, the change first goes to the |
| 276 | local clone, where file system permissions are all that matter, but then |
| 277 | upon sync, the situation is effectively the same as when the parent repo |
| 278 | is on the local file system. If you can log into the remote system over |
| 279 | SSH and that user has the necessary file system permissions on that |
| 280 | remote repo DB file, it is the same situation as for `file://` URLs. |
| 281 | |
| 282 | All Fossil syncs are done over HTTP, even for `file://` and `ssh://` |
| 283 | URLs: |
| 284 | |
| 285 | * For `ssh://` URLs, Fossil pipes the HTTP conversation through a |
| 286 | local SSH client to a remote instance of Fossil running the |
| 287 | [`test-http`](/help?name=test-http) command to recieve the tunneled |
| 288 | HTTP connection without cap checks. The SSH client defaults to “`ssh |
| 289 | -e none -T`” on most platforms, except on Windows where it defaults |
| 290 | to “`plink -ssh -T`”. You can override this with [the `ssh-command` |
| 291 | setting](/help?name=ssh-command). |
| 292 | |
| 293 | * For `file://` URLs, the “sending” Fossil instance writes its side of |
| 294 | the HTTP conversation out to a temporary file in the same directory |
| 295 | as the local repo clone and then calls itself on the “receiving” |
| 296 | repository to read that same HTTP transcript file back in to apply |
| 297 | those changes to that repository. Presumably Fossil doesn’t do this |
| 298 | with a pipe to ease portability to Windows. |
| 299 | |
| 300 | Because both mechanisms work on local repos, the checks for capabilities |
| 301 | like [**Read**][o] and [**Write**][i] within the HTTP conversation for |
| 302 | such URLs can never return “false,” because you are the [**Setup**][s] |
| 303 | user on both sides of the conversation. Such checks only have a useful |
| 304 | effect when done over an `http[s]://` URL. |
| 305 | |
| 306 | |
| 307 | ## <a name="pubpg"></a>Public Pages |
| 308 | |
| 309 | In Admin → Access, there is an option for giving a list of [globs][glob] |
| @@ -349,7 +368,7 @@ | |
| 368 | [7]: ./ref.html#7 |
| 369 | |
| 370 | [glob]: https://en.wikipedia.org/wiki/Glob_(programming) |
| 371 | [japi]: https://docs.google.com/document/d/1fXViveNhDbiXgCuE7QDXQOKeFzf2qNUkBEgiUvoqFN4/view#heading=h.6k0k5plm18p1 |
| 372 | [sp]: ../sync.wiki |
| 373 | [sync]: /help?name=sync |
| 374 | [wp]: /help#webpages |
| 375 |