Fossil SCM
Clarified the points in §5.2.1 of the Docker container build doc regarding the reason why the server parent process runs as root.
Commit
c2eaa60da9bde441aa45b317630e117236a8a719f09f5af927a09813406ec3c2
Parent
f715add9381024a…
1 file changed
+14
-10
+14
-10
| --- www/build.wiki | ||
| +++ www/build.wiki | ||
| @@ -410,20 +410,24 @@ | ||
| 410 | 410 | we deem this risk low since a) it's never happened, that we know of; |
| 411 | 411 | and b) we haven't enabled any of the risky features of Fossil such as |
| 412 | 412 | [https://fossil-scm.org/forum/forumpost/42e0c16544 | TH1 docs]. |
| 413 | 413 | Nevertheless, we believe in defense-in-depth. |
| 414 | 414 | |
| 415 | -If you say "<tt>docker exec fossil ps</tt>", you're likely to find | |
| 416 | -a single <tt>fossil</tt> process running as <tt>root</tt> even though the chroot feature | |
| 417 | -is documented as causing Fossil to drop its privileges in favor of | |
| 418 | -the owner of the repository database or its containing folder. | |
| 419 | -If the repo file is owned by "fossil," why is the server still running as root? | |
| 420 | - | |
| 421 | -It's because you're likely seeing only the parent | |
| 422 | -process, which may need to do rootly things like listening on port 80 or | |
| 423 | -443. Fossil's chroot feature only takes effect in the child processes, | |
| 424 | -the ones forked off to handle each HTTP/CGI hit. This is why you can fix broken | |
| 415 | +If you say something like "<tt>docker exec fossil ps</tt>" while the | |
| 416 | +system is idle, it's likely to report a single <tt>fossil</tt> process | |
| 417 | +running as <tt>root</tt> even though the chroot feature is documented as | |
| 418 | +causing Fossil to drop its privileges in favor of the owner of the | |
| 419 | +repository database or its containing folder. If the repo file is owned | |
| 420 | +by the in-container user "<tt>fossil</tt>", why is the server still | |
| 421 | +running as root? | |
| 422 | + | |
| 423 | +It's because you're seeing only the parent | |
| 424 | +process, which assumes it's running on bare metal or a VM and thus | |
| 425 | +may need to do rootly things like listening on port 80 or | |
| 426 | +443 before forking off any children to handle HTTP hits. | |
| 427 | +Fossil's chroot feature only takes effect in these child processes. | |
| 428 | +This is why you can fix broken | |
| 425 | 429 | permissions with <tt>chown</tt> after the container is already running, |
| 426 | 430 | without restarting it: each hit reevaluates the repository file |
| 427 | 431 | permissions when deciding what user to become when dropping root |
| 428 | 432 | privileges. |
| 429 | 433 | |
| 430 | 434 |
| --- www/build.wiki | |
| +++ www/build.wiki | |
| @@ -410,20 +410,24 @@ | |
| 410 | we deem this risk low since a) it's never happened, that we know of; |
| 411 | and b) we haven't enabled any of the risky features of Fossil such as |
| 412 | [https://fossil-scm.org/forum/forumpost/42e0c16544 | TH1 docs]. |
| 413 | Nevertheless, we believe in defense-in-depth. |
| 414 | |
| 415 | If you say "<tt>docker exec fossil ps</tt>", you're likely to find |
| 416 | a single <tt>fossil</tt> process running as <tt>root</tt> even though the chroot feature |
| 417 | is documented as causing Fossil to drop its privileges in favor of |
| 418 | the owner of the repository database or its containing folder. |
| 419 | If the repo file is owned by "fossil," why is the server still running as root? |
| 420 | |
| 421 | It's because you're likely seeing only the parent |
| 422 | process, which may need to do rootly things like listening on port 80 or |
| 423 | 443. Fossil's chroot feature only takes effect in the child processes, |
| 424 | the ones forked off to handle each HTTP/CGI hit. This is why you can fix broken |
| 425 | permissions with <tt>chown</tt> after the container is already running, |
| 426 | without restarting it: each hit reevaluates the repository file |
| 427 | permissions when deciding what user to become when dropping root |
| 428 | privileges. |
| 429 | |
| 430 |
| --- www/build.wiki | |
| +++ www/build.wiki | |
| @@ -410,20 +410,24 @@ | |
| 410 | we deem this risk low since a) it's never happened, that we know of; |
| 411 | and b) we haven't enabled any of the risky features of Fossil such as |
| 412 | [https://fossil-scm.org/forum/forumpost/42e0c16544 | TH1 docs]. |
| 413 | Nevertheless, we believe in defense-in-depth. |
| 414 | |
| 415 | If you say something like "<tt>docker exec fossil ps</tt>" while the |
| 416 | system is idle, it's likely to report a single <tt>fossil</tt> process |
| 417 | running as <tt>root</tt> even though the chroot feature is documented as |
| 418 | causing Fossil to drop its privileges in favor of the owner of the |
| 419 | repository database or its containing folder. If the repo file is owned |
| 420 | by the in-container user "<tt>fossil</tt>", why is the server still |
| 421 | running as root? |
| 422 | |
| 423 | It's because you're seeing only the parent |
| 424 | process, which assumes it's running on bare metal or a VM and thus |
| 425 | may need to do rootly things like listening on port 80 or |
| 426 | 443 before forking off any children to handle HTTP hits. |
| 427 | Fossil's chroot feature only takes effect in these child processes. |
| 428 | This is why you can fix broken |
| 429 | permissions with <tt>chown</tt> after the container is already running, |
| 430 | without restarting it: each hit reevaluates the repository file |
| 431 | permissions when deciding what user to become when dropping root |
| 432 | privileges. |
| 433 | |
| 434 |