Fossil SCM

Clarified the parent process user ID vs the child process in the explanation of how the chroot feature interacts with the custom user feature of the Docker container.

wyoung 2022-08-28 17:58 trunk
Commit f9ddd38ecc2b571638e385848dc6572f523853cbc02df366e99a3aa896e0d2f8
1 file changed +7 -3
+7 -3
--- www/build.wiki
+++ www/build.wiki
@@ -403,14 +403,18 @@
403403
We deem this risk low since a) it's never happened, that we know of;
404404
and b) we've turned off all of the risky features like TH1 docs.
405405
Nevertheless, we believe in defense-in-depth.
406406
407407
If you shell into the container and do a <tt>ps</tt>, you'll find
408
-<tt>fossil</tt> running as <tt>root</tt>. Why? Because that's the parent
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
409413
process, which may need to do rootly things like listening on port 80 or
410
-443. Fossil's chroot feature takes effect in the child processes forked
411
-off to handle each HTTP/CGI hit. This is why you can fix broken
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
412416
permissions with <tt>chown</tt> after the container is already running,
413417
without restarting it: each hit reevaluates the repository file
414418
permissions when deciding what user to become when dropping root
415419
privileges.
416420
417421
--- www/build.wiki
+++ www/build.wiki
@@ -403,14 +403,18 @@
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>. Why? Because that's the parent
 
 
 
 
409 process, which may need to do rootly things like listening on port 80 or
410 443. Fossil's chroot feature takes effect in the child processes forked
411 off to handle each HTTP/CGI hit. This is why you can fix broken
412 permissions with <tt>chown</tt> after the container is already running,
413 without restarting it: each hit reevaluates the repository file
414 permissions when deciding what user to become when dropping root
415 privileges.
416
417
--- www/build.wiki
+++ www/build.wiki
@@ -403,14 +403,18 @@
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 permissions when deciding what user to become when dropping root
419 privileges.
420
421

Keyboard Shortcuts

Open search /
Next entry (timeline) j
Previous entry (timeline) k
Open focused entry Enter
Show this help ?
Toggle theme Top nav button