Fossil SCM
Clarified the read/write access issue in the #webonly section of the main user capabilities doc.
Commit
391bc369872059c6fe21eef90a0e61ee0b07d552ff5977183c97a59098aa6e18
Parent
76f65b4362bce05…
1 file changed
+12
-5
+12
-5
| --- www/caps/index.md | ||
| +++ www/caps/index.md | ||
| @@ -263,17 +263,24 @@ | ||
| 263 | 263 | JSON API][japi]. For everything else, the user caps aren’t consulted at |
| 264 | 264 | all. |
| 265 | 265 | |
| 266 | 266 | The only checks made when working directly with a local repository are |
| 267 | 267 | the operating system’s file system permissions. This should strike you |
| 268 | -as sensible, since if you have local file access to the repository, you | |
| 269 | -can do anything you want to that repo DB including adding a | |
| 270 | -[**Setup**][s] user for yourself, after which Fossil’s user capability | |
| 271 | -system is effectively bypassed. This is why the `fossil ui` command | |
| 268 | +as sensible, since if you have read access to the repository file, you | |
| 269 | +can do anything you want to that repo DB including giving your user’s | |
| 270 | +record the [**Setup**][s] capability, after which Fossil’s user | |
| 271 | +capability system is effectively bypassed. (Or, create another Setup | |
| 272 | +user, with the same end effect.) If you’re objecting that you need | |
| 273 | +*write* access to the DB file to achieve this, realize that you can copy | |
| 274 | +a read-only file to another location, giving yourself write access to | |
| 275 | +it. | |
| 276 | + | |
| 277 | +This is why the `fossil ui` command | |
| 272 | 278 | gives you Setup permissions within Fossil UI: it can’t usefully prevent |
| 273 | 279 | you from doing anything through the UI since only the local file system |
| 274 | -permissions actually matter. | |
| 280 | +permissions actually matter, and you can’t start `fossil ui` without | |
| 281 | +having at least read access to that file. | |
| 275 | 282 | |
| 276 | 283 | What may be more surprising to you is that this is also true when |
| 277 | 284 | working on a *clone* done over a local file path, except that there are |
| 278 | 285 | then two sets of file system permission checks: once to modify the |
| 279 | 286 | working check-out’s repo clone DB file, then again on [sync][sync] with |
| 280 | 287 |
| --- www/caps/index.md | |
| +++ www/caps/index.md | |
| @@ -263,17 +263,24 @@ | |
| 263 | JSON API][japi]. For everything else, the user caps aren’t consulted at |
| 264 | all. |
| 265 | |
| 266 | The only checks made when working directly with a local repository are |
| 267 | the operating system’s file system permissions. This should strike you |
| 268 | as sensible, since if you have local file access to the repository, you |
| 269 | can do anything you want to that repo DB including adding a |
| 270 | [**Setup**][s] user for yourself, after which Fossil’s user capability |
| 271 | system is effectively bypassed. This is why the `fossil ui` command |
| 272 | gives you Setup permissions within Fossil UI: it can’t usefully prevent |
| 273 | you from doing anything through the UI since only the local file system |
| 274 | permissions actually matter. |
| 275 | |
| 276 | What may be more surprising to you is that this is also true when |
| 277 | working on a *clone* done over a local file path, except that there are |
| 278 | then two sets of file system permission checks: once to modify the |
| 279 | working check-out’s repo clone DB file, then again on [sync][sync] with |
| 280 |
| --- www/caps/index.md | |
| +++ www/caps/index.md | |
| @@ -263,17 +263,24 @@ | |
| 263 | JSON API][japi]. For everything else, the user caps aren’t consulted at |
| 264 | all. |
| 265 | |
| 266 | The only checks made when working directly with a local repository are |
| 267 | the operating system’s file system permissions. This should strike you |
| 268 | as sensible, since if you have read access to the repository file, you |
| 269 | can do anything you want to that repo DB including giving your user’s |
| 270 | record the [**Setup**][s] capability, after which Fossil’s user |
| 271 | capability system is effectively bypassed. (Or, create another Setup |
| 272 | user, with the same end effect.) If you’re objecting that you need |
| 273 | *write* access to the DB file to achieve this, realize that you can copy |
| 274 | a read-only file to another location, giving yourself write access to |
| 275 | it. |
| 276 | |
| 277 | This is why the `fossil ui` command |
| 278 | gives you Setup permissions within Fossil UI: it can’t usefully prevent |
| 279 | you from doing anything through the UI since only the local file system |
| 280 | permissions actually matter, and you can’t start `fossil ui` without |
| 281 | having at least read access to that file. |
| 282 | |
| 283 | What may be more surprising to you is that this is also true when |
| 284 | working on a *clone* done over a local file path, except that there are |
| 285 | then two sets of file system permission checks: once to modify the |
| 286 | working check-out’s repo clone DB file, then again on [sync][sync] with |
| 287 |