Run CDN in a Box for Developers services as unprivileged users

[zrhoffman]

This PR makes it so that when the CDN in a Box for Developers services create new files (from npm ci, building debug binaries, creating Traffic Router DBs, etc.), the files are owned by the user who owns the repository directory, rather than being owned by root.

---

Which Traffic Control components are affected by this PR?

• CDN in a Box - for Developers

What is the best way to verify this PR?

1. Remove generated files and directories:

   rm -rf dev/traffic_router/db experimental/traffic-portal/node_modules traffic_monitor/__debug_bin traffic_ops/traffic_ops_golang/__debug_bin traffic_portal/node_modules

2. Build the CDN in a Box for Developers:

   docker-compose build

3. Start the Dev CiaB:

   docker-compose up

4. Verify that the generated files and directories are owned by you

ls -ld dev/traffic_router/db experimental/traffic-portal/node_modules traffic_monitor/__debug_bin traffic_ops/traffic_ops_golang/__debug_bin traffic_portal/node_modules

PR submission checklist

• This PR has tests
• This PR has documentation
• This PR has a CHANGELOG.md entry
• This PR DOES NOT FIX A SERIOUS SECURITY VULNERABILITY (see the Apache Software Foundation's security guidelines for details)

[ocket8888]

This is something I've wanted for the dev environment since its inception, but I can't test it because of a bug in the TP/TPv2 containers that prevents them from fetching a resource from npm. I've had another developer confirm that the issue is not specific to my machine, but I still have no idea why that's happening.

[zrhoffman]

Rebased onto master to get #7164

[ocket8888]

Most things appear to be working, but it seems that the Go binaries it generates are still owned by root:

$ ls -lR . | grep -v "$(whoami)" | grep -vE '^\..*:$' | grep -vE '^$' | grep -vE '^total [0-9]+$'
-rwxr-xr-x 1 root      root      6881051 Nov  9 10:57 t3c
-rwxr-xr-x 1 root      root      9965720 Nov  9 10:57 t3c-apply
-rwxr-xr-x 1 root      root      6876971 Nov  9 10:57 t3c-check
-rwxr-xr-x 1 root      root      6958591 Nov  9 10:57 t3c-check-refs
-rwxr-xr-x 1 root      root      6854750 Nov  9 10:57 t3c-check-reload
-rwxr-xr-x 1 root      root      6958920 Nov  9 10:57 t3c-diff
-rwxr-xr-x 1 root      root      8375868 Nov  9 10:57 t3c-generate
-rwxr-xr-x 1 root      root      6960525 Nov  9 10:57 t3c-preprocess
-rwxr-xr-x 1 root      root      10250226 Nov  9 10:57 t3c-request
-rwxr-xr-x 1 root      root      7076256 Nov  9 10:57 t3c-tail
-rwxr-xr-x 1 root      root      9794976 Nov  9 10:57 t3c-update
-rwxr-xr-x 1 root      root      11172798 Nov  9 10:57 tc-health-client
-rwxr-xr-x 1 root      root      7106164 Nov  9 10:56 admin

[ericholguin]

Maybe should be changed to 23 so ssh port isnt exposed?

[zrhoffman]

This isn't which ports are exposed, it's which ports a non-root user is allowed to listen on.

Docker itself includes net.ipv4.ip_unprivileged_port_start = 0, just not containerd yet.

[zrhoffman]

Oops, the condition checking if t3c's run.sh was being run as root was always checking the unprivileged user's UID instead. Fixed in 0150a22