Fossil SCM
Grepped the Fossil source code for C code that checks for Setup caps exclusively to preotect functions and listed those in the Reference section of capablities.md. Also expanded the coverage of the "caps affect Fossil web interfaces only" section, which plays into this.
Commit
689f7683b694a0beb93291ef8326a1a35fe0f59ba8778f89ec3d0925860284d0
Parent
208ca0d713d9321…
1 file changed
+48
-27
+48
-27
| --- www/capabilities.md | ||
| +++ www/capabilities.md | ||
| @@ -239,11 +239,11 @@ | ||
| 239 | 239 | login group. |
| 240 | 240 | |
| 241 | 241 | [lg]: /help?cmd=login-group |
| 242 | 242 | |
| 243 | 243 | |
| 244 | -## <a name="utclone" id="ssh"></a>Cloning the User Table | |
| 244 | +## <a name="utclone"></a>Cloning the User Table | |
| 245 | 245 | |
| 246 | 246 | When cloning over HTTP, the initial user table in the local clone is set |
| 247 | 247 | to its “[new state:](#new)” only one user with Setup capability, named |
| 248 | 248 | after either [your OS user account](#defuser) or after the user given in |
| 249 | 249 | the clone URL. |
| @@ -259,42 +259,42 @@ | ||
| 259 | 259 | get a complete clone, including the parent repo’s complete user table. |
| 260 | 260 | |
| 261 | 261 | All of the above applies to [login groups](#group) as well. |
| 262 | 262 | |
| 263 | 263 | |
| 264 | -## <a name="fssync" id="ssh"></a>Caps Affect Web Interfaces Only | |
| 265 | - | |
| 266 | -User caps only affect Fossil’s [UI pages][wp] and clones done over | |
| 267 | -`http[s]://` URLs. If you use any other URL type, Fossil will not check | |
| 268 | -user caps. | |
| 269 | - | |
| 270 | -This is sensible when working only on a local repository: only local | |
| 271 | -file permissions matter when operating on a local SQLite DB file. The | |
| 272 | -same sense extends to clones done via a file system path | |
| 273 | -(`/path/to/repo.fossil`) or through a `file://` URL. The only difference | |
| 274 | -is that there are two sets of file system permission checks: once to | |
| 275 | -modify the working check-out’s repo clone DB file, then again on | |
| 264 | +## <a name="webonly"></a>Caps Affect Web Interfaces Only | |
| 265 | + | |
| 266 | +User caps only affect Fossil’s [UI pages][wp], remote operations over | |
| 267 | +`http[s]://` URLs, and [the JSON API][japi]. | |
| 268 | + | |
| 269 | +User caps *do not* affect operations done on a local repo opened via a | |
| 270 | +`file://` URL or a file system path. This should strike you as sensible: | |
| 271 | +only local file permissions matter when operating on a local SQLite DB | |
| 272 | +file. The same is true when working on a clone done over such a path, | |
| 273 | +except that there are then two sets of file system permission checks: | |
| 274 | +once to modify the working check-out’s repo clone DB file, then again on | |
| 276 | 275 | [sync][sync] with the parent DB file. |
| 277 | 276 | |
| 278 | -However, Fossil *also* ignores caps when working on a repo cloned over | |
| 279 | -SSH! When you make a change to such a repository, the change first goes | |
| 280 | -to the local clone, where file system permissions are all that matter, | |
| 281 | -but then upon sync, the situation is effectively the same as when the | |
| 282 | -parent repo is on the local file system. If you can log into the remote | |
| 283 | -system over SSH and that user has the necessary file system permissions | |
| 284 | -on that remote repo DB file, your user is effectively the [all-powerful | |
| 285 | -Setup user](#apsu) on both sides of the SSH connection. | |
| 277 | +What may surprise you is that user caps *also do not affect SSH!* When | |
| 278 | +you make a change to such a repository, the change first goes to the | |
| 279 | +local clone, where file system permissions are all that matter, but then | |
| 280 | +upon sync, the situation is effectively the same as when the parent repo | |
| 281 | +is on the local file system. If you can log into the remote system over | |
| 282 | +SSH and that user has the necessary file system permissions on that | |
| 283 | +remote repo DB file, your user is effectively the [all-powerful Setup | |
| 284 | +user](#apsu) on both sides of the SSH connection. | |
| 286 | 285 | |
| 287 | 286 | Fossil reuses the HTTP-based [sync protocol][sp] in both cases above, |
| 288 | 287 | tunnelling HTTP through an OS pipe or through SSH (FIXME?), but all of |
| 289 | -the user cap checks in Fossil are on the web UI route handlers only. | |
| 288 | +the user cap checks in Fossil are on its web interfaces only. | |
| 290 | 289 | |
| 291 | 290 | TODO: Why then can I not `/xfer` my local repo contents to a remote repo |
| 292 | 291 | without logging in? |
| 293 | 292 | |
| 294 | -[sp]: ./sync.wiki | |
| 295 | -[wp]: /help#webpages | |
| 293 | +[japi]: https://docs.google.com/document/d/1fXViveNhDbiXgCuE7QDXQOKeFzf2qNUkBEgiUvoqFN4/view#heading=h.6k0k5plm18p1 | |
| 294 | +[sp]: ./sync.wiki | |
| 295 | +[wp]: /help#webpages | |
| 296 | 296 | |
| 297 | 297 | |
| 298 | 298 | ## <a name="apsu"></a>The All-Powerful Setup User |
| 299 | 299 | |
| 300 | 300 | A user with [Setup capability, **s**](#s) needs no other user |
| @@ -392,11 +392,11 @@ | ||
| 392 | 392 | **h**yperlink. |
| 393 | 393 | |
| 394 | 394 | * <a name="i"></a>**i (Write)** — Check changes into the repository. Note that |
| 395 | 395 | a lack of this capability does not prevent you from checking changes |
| 396 | 396 | into your local clone, only from syncing those changes up to the |
| 397 | - parent repo, and then [only over HTTP](#fssync). Granting this | |
| 397 | + parent repo, and then [only over HTTP](#webonly). Granting this | |
| 398 | 398 | capability also grants **o (Read)**. Mnemonic: check **i**n |
| 399 | 399 | changes. |
| 400 | 400 | |
| 401 | 401 | * <a name="j"></a>**j (RdWiki)** — View wiki articles. Mnemonic: in**j**est |
| 402 | 402 | page content. (All right, you critics, you do better, then.) |
| @@ -416,11 +416,11 @@ | ||
| 416 | 416 | * <a name="n"></a>**n (NewTkt)** — File new tickets. Mnemonic: **n**ew ticket. |
| 417 | 417 | |
| 418 | 418 | * <a name="o"></a>**o (Read)** — Read repository content from a remote |
| 419 | 419 | Fossil instance over HTTP. This capability has nothing to do with |
| 420 | 420 | reading data from a local repository, because [caps affect Fossil’s |
| 421 | - web interfaces only](#fssync). Once you’ve cloned a remote | |
| 421 | + web interfaces only](#webonly). Once you’ve cloned a remote | |
| 422 | 422 | repository to your local machine, you can do any reading you want on |
| 423 | 423 | that repository irrespective of whether your user has **o** |
| 424 | 424 | capability; the repo clone is completely under your user’s power at |
| 425 | 425 | that point, affectted only by OS file permissions and such. (To |
| 426 | 426 | prevent cloning, see [**g**](#g).) |
| @@ -440,11 +440,32 @@ | ||
| 440 | 440 | **q**uash noise commentary. |
| 441 | 441 | |
| 442 | 442 | * <a name="r"></a>**r (RdTkt)** — View existing tickets. Mnemonic: **r**ead |
| 443 | 443 | tickets. |
| 444 | 444 | |
| 445 | -* <a name="s"></a>**s (Setup)** — The [all-powerful Setup user](#apsu). | |
| 445 | +* <a name="s"></a>**s (Setup)** — The [all-powerful Setup user](#apsu) who | |
| 446 | + can uniquely: | |
| 447 | + | |
| 448 | + * Use roughly half of the Admin page settings | |
| 449 | + * See record IDs (RIDs) on screens that show them | |
| 450 | + * See the MIME type of attachments on [`/ainfo` pages](/help?cmd=/ainfo) | |
| 451 | + * See a remote repo’s HTTP [cache status](/help?cmd=/cachestat) | |
| 452 | + and [pull cache entries](/help?cmd=/cacheget) | |
| 453 | + * TODO: fold in results of [the timestamp override thread](https://fossil-scm.org/forum/forumpost/ee950efd2d) | |
| 454 | + * Edit a Setup user’s account! | |
| 455 | + | |
| 456 | + The Admin pages that only Setup can use are: Access, Configuration, | |
| 457 | + Email-Server, Login-Group, Notification, Settings, SQL, TH1, | |
| 458 | + Tickets, Transfers (TH1 hooks), and Wiki. | |
| 459 | + | |
| 460 | + Remember, [user caps affect Fossil’s web interfaces](#webonly) only. | |
| 461 | + A user can do anything they like to a repo stored on their local | |
| 462 | + machine. Fossil protects itself against malcious pushes, but someone | |
| 463 | + with clone and push capability on your repo could clone it, modify | |
| 464 | + their local repo as the local default Setup user account they got on | |
| 465 | + clone, and then push the changes back to your repo. | |
| 466 | + | |
| 446 | 467 | Mnemonics: **s**etup or **s**uperuser. |
| 447 | 468 | |
| 448 | 469 | * <a name="t"></a>**t (TktFmt)** — Create new ticket report formats. Note that |
| 449 | 470 | although this allows the user to provide SQL code to be run in the |
| 450 | 471 | server’s context, and this capability is given to the untrusted |
| 451 | 472 |
| --- www/capabilities.md | |
| +++ www/capabilities.md | |
| @@ -239,11 +239,11 @@ | |
| 239 | login group. |
| 240 | |
| 241 | [lg]: /help?cmd=login-group |
| 242 | |
| 243 | |
| 244 | ## <a name="utclone" id="ssh"></a>Cloning the User Table |
| 245 | |
| 246 | When cloning over HTTP, the initial user table in the local clone is set |
| 247 | to its “[new state:](#new)” only one user with Setup capability, named |
| 248 | after either [your OS user account](#defuser) or after the user given in |
| 249 | the clone URL. |
| @@ -259,42 +259,42 @@ | |
| 259 | get a complete clone, including the parent repo’s complete user table. |
| 260 | |
| 261 | All of the above applies to [login groups](#group) as well. |
| 262 | |
| 263 | |
| 264 | ## <a name="fssync" id="ssh"></a>Caps Affect Web Interfaces Only |
| 265 | |
| 266 | User caps only affect Fossil’s [UI pages][wp] and clones done over |
| 267 | `http[s]://` URLs. If you use any other URL type, Fossil will not check |
| 268 | user caps. |
| 269 | |
| 270 | This is sensible when working only on a local repository: only local |
| 271 | file permissions matter when operating on a local SQLite DB file. The |
| 272 | same sense extends to clones done via a file system path |
| 273 | (`/path/to/repo.fossil`) or through a `file://` URL. The only difference |
| 274 | is that there are two sets of file system permission checks: once to |
| 275 | modify the working check-out’s repo clone DB file, then again on |
| 276 | [sync][sync] with the parent DB file. |
| 277 | |
| 278 | However, Fossil *also* ignores caps when working on a repo cloned over |
| 279 | SSH! When you make a change to such a repository, the change first goes |
| 280 | to the local clone, where file system permissions are all that matter, |
| 281 | but then upon sync, the situation is effectively the same as when the |
| 282 | parent repo is on the local file system. If you can log into the remote |
| 283 | system over SSH and that user has the necessary file system permissions |
| 284 | on that remote repo DB file, your user is effectively the [all-powerful |
| 285 | Setup user](#apsu) on both sides of the SSH connection. |
| 286 | |
| 287 | Fossil reuses the HTTP-based [sync protocol][sp] in both cases above, |
| 288 | tunnelling HTTP through an OS pipe or through SSH (FIXME?), but all of |
| 289 | the user cap checks in Fossil are on the web UI route handlers only. |
| 290 | |
| 291 | TODO: Why then can I not `/xfer` my local repo contents to a remote repo |
| 292 | without logging in? |
| 293 | |
| 294 | [sp]: ./sync.wiki |
| 295 | [wp]: /help#webpages |
| 296 | |
| 297 | |
| 298 | ## <a name="apsu"></a>The All-Powerful Setup User |
| 299 | |
| 300 | A user with [Setup capability, **s**](#s) needs no other user |
| @@ -392,11 +392,11 @@ | |
| 392 | **h**yperlink. |
| 393 | |
| 394 | * <a name="i"></a>**i (Write)** — Check changes into the repository. Note that |
| 395 | a lack of this capability does not prevent you from checking changes |
| 396 | into your local clone, only from syncing those changes up to the |
| 397 | parent repo, and then [only over HTTP](#fssync). Granting this |
| 398 | capability also grants **o (Read)**. Mnemonic: check **i**n |
| 399 | changes. |
| 400 | |
| 401 | * <a name="j"></a>**j (RdWiki)** — View wiki articles. Mnemonic: in**j**est |
| 402 | page content. (All right, you critics, you do better, then.) |
| @@ -416,11 +416,11 @@ | |
| 416 | * <a name="n"></a>**n (NewTkt)** — File new tickets. Mnemonic: **n**ew ticket. |
| 417 | |
| 418 | * <a name="o"></a>**o (Read)** — Read repository content from a remote |
| 419 | Fossil instance over HTTP. This capability has nothing to do with |
| 420 | reading data from a local repository, because [caps affect Fossil’s |
| 421 | web interfaces only](#fssync). Once you’ve cloned a remote |
| 422 | repository to your local machine, you can do any reading you want on |
| 423 | that repository irrespective of whether your user has **o** |
| 424 | capability; the repo clone is completely under your user’s power at |
| 425 | that point, affectted only by OS file permissions and such. (To |
| 426 | prevent cloning, see [**g**](#g).) |
| @@ -440,11 +440,32 @@ | |
| 440 | **q**uash noise commentary. |
| 441 | |
| 442 | * <a name="r"></a>**r (RdTkt)** — View existing tickets. Mnemonic: **r**ead |
| 443 | tickets. |
| 444 | |
| 445 | * <a name="s"></a>**s (Setup)** — The [all-powerful Setup user](#apsu). |
| 446 | Mnemonics: **s**etup or **s**uperuser. |
| 447 | |
| 448 | * <a name="t"></a>**t (TktFmt)** — Create new ticket report formats. Note that |
| 449 | although this allows the user to provide SQL code to be run in the |
| 450 | server’s context, and this capability is given to the untrusted |
| 451 |
| --- www/capabilities.md | |
| +++ www/capabilities.md | |
| @@ -239,11 +239,11 @@ | |
| 239 | login group. |
| 240 | |
| 241 | [lg]: /help?cmd=login-group |
| 242 | |
| 243 | |
| 244 | ## <a name="utclone"></a>Cloning the User Table |
| 245 | |
| 246 | When cloning over HTTP, the initial user table in the local clone is set |
| 247 | to its “[new state:](#new)” only one user with Setup capability, named |
| 248 | after either [your OS user account](#defuser) or after the user given in |
| 249 | the clone URL. |
| @@ -259,42 +259,42 @@ | |
| 259 | get a complete clone, including the parent repo’s complete user table. |
| 260 | |
| 261 | All of the above applies to [login groups](#group) as well. |
| 262 | |
| 263 | |
| 264 | ## <a name="webonly"></a>Caps Affect Web Interfaces Only |
| 265 | |
| 266 | User caps only affect Fossil’s [UI pages][wp], remote operations over |
| 267 | `http[s]://` URLs, and [the JSON API][japi]. |
| 268 | |
| 269 | User caps *do not* affect operations done on a local repo opened via a |
| 270 | `file://` URL or a file system path. This should strike you as sensible: |
| 271 | only local file permissions matter when operating on a local SQLite DB |
| 272 | file. The same is true when working on a clone done over such a path, |
| 273 | except that there are then two sets of file system permission checks: |
| 274 | once to modify the working check-out’s repo clone DB file, then again on |
| 275 | [sync][sync] with the parent DB file. |
| 276 | |
| 277 | What may surprise you is that user caps *also do not affect SSH!* When |
| 278 | you make a change to such a repository, the change first goes to the |
| 279 | local clone, where file system permissions are all that matter, but then |
| 280 | upon sync, the situation is effectively the same as when the parent repo |
| 281 | is on the local file system. If you can log into the remote system over |
| 282 | SSH and that user has the necessary file system permissions on that |
| 283 | remote repo DB file, your user is effectively the [all-powerful Setup |
| 284 | user](#apsu) on both sides of the SSH connection. |
| 285 | |
| 286 | Fossil reuses the HTTP-based [sync protocol][sp] in both cases above, |
| 287 | tunnelling HTTP through an OS pipe or through SSH (FIXME?), but all of |
| 288 | the user cap checks in Fossil are on its web interfaces only. |
| 289 | |
| 290 | TODO: Why then can I not `/xfer` my local repo contents to a remote repo |
| 291 | without logging in? |
| 292 | |
| 293 | [japi]: https://docs.google.com/document/d/1fXViveNhDbiXgCuE7QDXQOKeFzf2qNUkBEgiUvoqFN4/view#heading=h.6k0k5plm18p1 |
| 294 | [sp]: ./sync.wiki |
| 295 | [wp]: /help#webpages |
| 296 | |
| 297 | |
| 298 | ## <a name="apsu"></a>The All-Powerful Setup User |
| 299 | |
| 300 | A user with [Setup capability, **s**](#s) needs no other user |
| @@ -392,11 +392,11 @@ | |
| 392 | **h**yperlink. |
| 393 | |
| 394 | * <a name="i"></a>**i (Write)** — Check changes into the repository. Note that |
| 395 | a lack of this capability does not prevent you from checking changes |
| 396 | into your local clone, only from syncing those changes up to the |
| 397 | parent repo, and then [only over HTTP](#webonly). Granting this |
| 398 | capability also grants **o (Read)**. Mnemonic: check **i**n |
| 399 | changes. |
| 400 | |
| 401 | * <a name="j"></a>**j (RdWiki)** — View wiki articles. Mnemonic: in**j**est |
| 402 | page content. (All right, you critics, you do better, then.) |
| @@ -416,11 +416,11 @@ | |
| 416 | * <a name="n"></a>**n (NewTkt)** — File new tickets. Mnemonic: **n**ew ticket. |
| 417 | |
| 418 | * <a name="o"></a>**o (Read)** — Read repository content from a remote |
| 419 | Fossil instance over HTTP. This capability has nothing to do with |
| 420 | reading data from a local repository, because [caps affect Fossil’s |
| 421 | web interfaces only](#webonly). Once you’ve cloned a remote |
| 422 | repository to your local machine, you can do any reading you want on |
| 423 | that repository irrespective of whether your user has **o** |
| 424 | capability; the repo clone is completely under your user’s power at |
| 425 | that point, affectted only by OS file permissions and such. (To |
| 426 | prevent cloning, see [**g**](#g).) |
| @@ -440,11 +440,32 @@ | |
| 440 | **q**uash noise commentary. |
| 441 | |
| 442 | * <a name="r"></a>**r (RdTkt)** — View existing tickets. Mnemonic: **r**ead |
| 443 | tickets. |
| 444 | |
| 445 | * <a name="s"></a>**s (Setup)** — The [all-powerful Setup user](#apsu) who |
| 446 | can uniquely: |
| 447 | |
| 448 | * Use roughly half of the Admin page settings |
| 449 | * See record IDs (RIDs) on screens that show them |
| 450 | * See the MIME type of attachments on [`/ainfo` pages](/help?cmd=/ainfo) |
| 451 | * See a remote repo’s HTTP [cache status](/help?cmd=/cachestat) |
| 452 | and [pull cache entries](/help?cmd=/cacheget) |
| 453 | * TODO: fold in results of [the timestamp override thread](https://fossil-scm.org/forum/forumpost/ee950efd2d) |
| 454 | * Edit a Setup user’s account! |
| 455 | |
| 456 | The Admin pages that only Setup can use are: Access, Configuration, |
| 457 | Email-Server, Login-Group, Notification, Settings, SQL, TH1, |
| 458 | Tickets, Transfers (TH1 hooks), and Wiki. |
| 459 | |
| 460 | Remember, [user caps affect Fossil’s web interfaces](#webonly) only. |
| 461 | A user can do anything they like to a repo stored on their local |
| 462 | machine. Fossil protects itself against malcious pushes, but someone |
| 463 | with clone and push capability on your repo could clone it, modify |
| 464 | their local repo as the local default Setup user account they got on |
| 465 | clone, and then push the changes back to your repo. |
| 466 | |
| 467 | Mnemonics: **s**etup or **s**uperuser. |
| 468 | |
| 469 | * <a name="t"></a>**t (TktFmt)** — Create new ticket report formats. Note that |
| 470 | although this allows the user to provide SQL code to be run in the |
| 471 | server’s context, and this capability is given to the untrusted |
| 472 |