Test reporter logging is owned by root if first work item is docker work item
See original GitHub issueIt seems in the scenario where the first work item a machine ever runs is in a docker scenario and uses the reporter, that machine will not be able to appened to the runner logs, as noted below:
bad machine: run.py (reporter log) is owned by root:
helixbot@a00C88M:~/dotnetbuild/logs$ ls -al
total 14048
drwxrwxrwx 2 helixbot root 4096 Apr 27 22:32 .
drwxr-xr-x 4 root root 4096 Apr 27 18:14 ..
-rw-r--r-- 1 helixbot helixbot 0 Apr 27 22:20 client_0_last_started
-rw-r--r-- 1 helixbot helixbot 6415 Apr 27 18:14 installer.log
-rw-r--r-- 1 root root 0 Apr 27 18:17 run.py.err
-rw-r--r-- 1 root root 2951 Apr 27 21:43 run.py.log
-rw-r--r-- 1 helixbot helixbot 6377 Apr 27 21:43 run_client.py.err
-rw-r--r-- 1 helixbot helixbot 14279979 Apr 27 22:55 run_client.py.log
-rw-r--r-- 1 helixbot helixbot 0 Apr 27 18:14 run_heartbeat.py.err
-rw-r--r-- 1 helixbot helixbot 61350 Apr 27 22:55 run_heartbeat.py.log
-rw-r--r-- 1 helixbot helixbot 0 Apr 27 18:14 start_helix.py.err
-rw-r--r-- 1 helixbot helixbot 194 Apr 27 18:14 start_helix.py.log
Good machine: run.py (reporter log) is owned by helixbot:
helixbot@a00C8C3:~/dotnetbuild/logs$ ls -al
total 2244
drwxrwxrwx 2 helixbot root 4096 Apr 27 22:57 .
drwxr-xr-x 4 root root 4096 Apr 27 22:47 ..
-rw-r--r-- 1 helixbot helixbot 0 Apr 27 22:56 client_0_last_started
-rw-r--r-- 1 helixbot helixbot 6415 Apr 27 22:47 installer.log
-rw-r--r-- 1 helixbot helixbot 0 Apr 27 22:48 run.py.err
-rw-r--r-- 1 helixbot helixbot 8019 Apr 27 22:57 run.py.log
-rw-r--r-- 1 helixbot helixbot 0 Apr 27 22:47 run_client.py.err
-rw-r--r-- 1 helixbot helixbot 2261292 Apr 27 22:57 run_client.py.log
-rw-r--r-- 1 helixbot helixbot 0 Apr 27 22:47 run_heartbeat.py.err
-rw-r--r-- 1 helixbot helixbot 2390 Apr 27 22:57 run_heartbeat.py.log
-rw-r--r-- 1 helixbot helixbot 0 Apr 27 22:47 start_helix.py.err
-rw-r--r-- 1 helixbot helixbot 194 Apr 27 22:47 start_helix.py.log
We could just change ownership of all log files every work item, but as a shorter term fix that’s much safer I will explore making the packing test reporter only log to the console; this will still be logged, and will not create files across the mounted volume with incorrect user ownership.
Adding Error message to track impact
{ "ErrorMessage":"PermissionError: [Errno 13] Permission denied: '/root/helix/logs/run.py.log'" }
Report
Summary
Day Hit Count | Week Hit Count | Month Hit Count |
---|---|---|
0 | 0 | 0 |
Issue Analytics
- State:
- Created a year ago
- Comments:8 (8 by maintainers)
Top Results From Across the Web
Docker Files and Volumes: Permission Denied
There is no d as first item because it is not a directory of course and the file does not have any execute...
Read more >Docker Logging: 101 Guide to Logs, Best Practices & More
Get started with Docker logging! Learn what container and daemon logs are and the best practices and strategies on how to view and...
Read more >10 things to avoid in docker containers | Red Hat Developer
1) Don't store data in containers - A container can be stopped, destroyed, or replaced. An application version 1.0 running in container should ......
Read more >docker service create
Swarm This command works with the Swarm orchestrator. ... be owned by the user who runs the command inside the container (often root...
Read more >Top 20 Dockerfile best practices for security
#1.3 Make executables owned by root and not writable. It is a Dockerfile best practice for every executable in a container to be...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
@danmoseley FYI
I figured out where this comes from. Mostly the docker tag
mcr.microsoft.com/dotnet-buildtools/prereqs:ubuntu-18.04-webassembly-20220408155625-5bc1463
is missing this bit, which causes the user inside the container to “match” outside the container:Hunting down the addition of this docker tag, I see it was added by thaystg seven days ago in https://github.com/dotnet/runtime/pull/61776. @thaystg, we’re trying to make this not break others in the future but ideally we should prepare a “user is UID 1000, and named helixbot” version of this for Helix testing if at all possible.