Fossil SCM
Polishing pass on §5.2 of the container build doc, "Why Chroot?"
Commit
e98603144b0440f15e0634aa9bccdca4c92fcd3b38956a977e2c63506c350e73
Parent
f9ddd38ecc2b571…
1 file changed
+18
-11
+18
-11
| --- www/build.wiki | ||
| +++ www/build.wiki | ||
| @@ -382,11 +382,11 @@ | ||
| 382 | 382 | <h3 id="docker-chroot">5.2 Why Chroot?</h3> |
| 383 | 383 | |
| 384 | 384 | A potentially surprising feature of this container is that it runs |
| 385 | 385 | Fossil as root. Since that causes [./chroot.md | Fossil's chroot jail |
| 386 | 386 | feature] to kick in, and a Docker container is a type of über-jail |
| 387 | -already, you may be wondering why we don't either: | |
| 387 | +already, you may be wondering why we bother. Instead, why not either: | |
| 388 | 388 | |
| 389 | 389 | # run <tt>fossil server --nojail</tt> to skip the internal chroot; or |
| 390 | 390 | # set "<tt>USER fossil</tt>" in the Dockerfile so it starts Fossil as |
| 391 | 391 | that user instead |
| 392 | 392 | |
| @@ -394,24 +394,31 @@ | ||
| 394 | 394 | standards, it's based on the [https://www.busybox.net/BusyBox.html | |
| 395 | 395 | surprisingly powerful Busybox project]. (This author made a living for |
| 396 | 396 | years in the early 1990s using Unix systems that were less powerful than |
| 397 | 397 | this container.) If someone ever figured out how to make a Fossil binary |
| 398 | 398 | execute arbitrary commands on the host or to open up a remote shell, |
| 399 | -they'd likely be able to island-hop from there into the rest of your | |
| 400 | -network. We need this cute double-jail dance to keep the Fossil instance | |
| 401 | -from accessing the Busybox features. | |
| 399 | +the power available to them at that point would make it likely that | |
| 400 | +they'd be able to island-hop from there into the rest of your network. | |
| 401 | +That power is there for you as the system administrator, to let you | |
| 402 | +inspect the container's runtime behavior, change things on the fly, and | |
| 403 | +so forth. Fossil proper doesn't need that power; if we take it away via | |
| 404 | +this cute double-jail dance, we keep any potential attacker from making | |
| 405 | +use of it should they ever get in. | |
| 402 | 406 | |
| 403 | -We deem this risk low since a) it's never happened, that we know of; | |
| 404 | -and b) we've turned off all of the risky features like TH1 docs. | |
| 407 | +Having said this, know that | |
| 408 | +we deem this risk low since a) it's never happened, that we know of; | |
| 409 | +and b) we haven't enabled any of the risky features of Fossil such as | |
| 410 | +[https://fossil-scm.org/forum/forumpost/42e0c16544 | TH1 docs]. | |
| 405 | 411 | Nevertheless, we believe in defense-in-depth. |
| 406 | 412 | |
| 407 | -If you shell into the container and do a <tt>ps</tt>, you'll find | |
| 408 | -<tt>fossil</tt> running as <tt>root</tt> even though the chroot feature | |
| 409 | -is documented as causing Fossil to drop its root privileges in favor of | |
| 413 | +If you say "<tt>docker exec fossil ps</tt>", you're likely to find | |
| 414 | +a single <tt>fossil</tt> process running as <tt>root</tt> even though the chroot feature | |
| 415 | +is documented as causing Fossil to drop its privileges in favor of | |
| 410 | 416 | the owner of the repository database or its containing folder. |
| 411 | -If the repo file is owned by "fossil," why is it still running as root? | |
| 412 | -It's because you're likley seeing only the parent | |
| 417 | +If the repo file is owned by "fossil," why is the server still running as root? | |
| 418 | + | |
| 419 | +It's because you're likely seeing only the parent | |
| 413 | 420 | process, which may need to do rootly things like listening on port 80 or |
| 414 | 421 | 443. Fossil's chroot feature only takes effect in the child processes, |
| 415 | 422 | the ones forked off to handle each HTTP/CGI hit. This is why you can fix broken |
| 416 | 423 | permissions with <tt>chown</tt> after the container is already running, |
| 417 | 424 | without restarting it: each hit reevaluates the repository file |
| 418 | 425 |
| --- www/build.wiki | |
| +++ www/build.wiki | |
| @@ -382,11 +382,11 @@ | |
| 382 | <h3 id="docker-chroot">5.2 Why Chroot?</h3> |
| 383 | |
| 384 | A potentially surprising feature of this container is that it runs |
| 385 | Fossil as root. Since that causes [./chroot.md | Fossil's chroot jail |
| 386 | feature] to kick in, and a Docker container is a type of über-jail |
| 387 | already, you may be wondering why we don't either: |
| 388 | |
| 389 | # run <tt>fossil server --nojail</tt> to skip the internal chroot; or |
| 390 | # set "<tt>USER fossil</tt>" in the Dockerfile so it starts Fossil as |
| 391 | that user instead |
| 392 | |
| @@ -394,24 +394,31 @@ | |
| 394 | standards, it's based on the [https://www.busybox.net/BusyBox.html | |
| 395 | surprisingly powerful Busybox project]. (This author made a living for |
| 396 | years in the early 1990s using Unix systems that were less powerful than |
| 397 | this container.) If someone ever figured out how to make a Fossil binary |
| 398 | execute arbitrary commands on the host or to open up a remote shell, |
| 399 | they'd likely be able to island-hop from there into the rest of your |
| 400 | network. We need this cute double-jail dance to keep the Fossil instance |
| 401 | from accessing the Busybox features. |
| 402 | |
| 403 | We deem this risk low since a) it's never happened, that we know of; |
| 404 | and b) we've turned off all of the risky features like TH1 docs. |
| 405 | Nevertheless, we believe in defense-in-depth. |
| 406 | |
| 407 | If you shell into the container and do a <tt>ps</tt>, you'll find |
| 408 | <tt>fossil</tt> running as <tt>root</tt> even though the chroot feature |
| 409 | is documented as causing Fossil to drop its root privileges in favor of |
| 410 | the owner of the repository database or its containing folder. |
| 411 | If the repo file is owned by "fossil," why is it still running as root? |
| 412 | It's because you're likley seeing only the parent |
| 413 | process, which may need to do rootly things like listening on port 80 or |
| 414 | 443. Fossil's chroot feature only takes effect in the child processes, |
| 415 | the ones forked off to handle each HTTP/CGI hit. This is why you can fix broken |
| 416 | permissions with <tt>chown</tt> after the container is already running, |
| 417 | without restarting it: each hit reevaluates the repository file |
| 418 |
| --- www/build.wiki | |
| +++ www/build.wiki | |
| @@ -382,11 +382,11 @@ | |
| 382 | <h3 id="docker-chroot">5.2 Why Chroot?</h3> |
| 383 | |
| 384 | A potentially surprising feature of this container is that it runs |
| 385 | Fossil as root. Since that causes [./chroot.md | Fossil's chroot jail |
| 386 | feature] to kick in, and a Docker container is a type of über-jail |
| 387 | already, you may be wondering why we bother. Instead, why not either: |
| 388 | |
| 389 | # run <tt>fossil server --nojail</tt> to skip the internal chroot; or |
| 390 | # set "<tt>USER fossil</tt>" in the Dockerfile so it starts Fossil as |
| 391 | that user instead |
| 392 | |
| @@ -394,24 +394,31 @@ | |
| 394 | standards, it's based on the [https://www.busybox.net/BusyBox.html | |
| 395 | surprisingly powerful Busybox project]. (This author made a living for |
| 396 | years in the early 1990s using Unix systems that were less powerful than |
| 397 | this container.) If someone ever figured out how to make a Fossil binary |
| 398 | execute arbitrary commands on the host or to open up a remote shell, |
| 399 | the power available to them at that point would make it likely that |
| 400 | they'd be able to island-hop from there into the rest of your network. |
| 401 | That power is there for you as the system administrator, to let you |
| 402 | inspect the container's runtime behavior, change things on the fly, and |
| 403 | so forth. Fossil proper doesn't need that power; if we take it away via |
| 404 | this cute double-jail dance, we keep any potential attacker from making |
| 405 | use of it should they ever get in. |
| 406 | |
| 407 | Having said this, know that |
| 408 | we deem this risk low since a) it's never happened, that we know of; |
| 409 | and b) we haven't enabled any of the risky features of Fossil such as |
| 410 | [https://fossil-scm.org/forum/forumpost/42e0c16544 | TH1 docs]. |
| 411 | Nevertheless, we believe in defense-in-depth. |
| 412 | |
| 413 | If you say "<tt>docker exec fossil ps</tt>", you're likely to find |
| 414 | a single <tt>fossil</tt> process running as <tt>root</tt> even though the chroot feature |
| 415 | is documented as causing Fossil to drop its privileges in favor of |
| 416 | the owner of the repository database or its containing folder. |
| 417 | If the repo file is owned by "fossil," why is the server still running as root? |
| 418 | |
| 419 | It's because you're likely seeing only the parent |
| 420 | process, which may need to do rootly things like listening on port 80 or |
| 421 | 443. Fossil's chroot feature only takes effect in the child processes, |
| 422 | the ones forked off to handle each HTTP/CGI hit. This is why you can fix broken |
| 423 | permissions with <tt>chown</tt> after the container is already running, |
| 424 | without restarting it: each hit reevaluates the repository file |
| 425 |