Sitespeed.io: Docker writes reports to host directory as root user

[ronderksen]

Today we ran into the issue that the sitespeed writes its report files to the host system as root. This caused our Jenkins CI to be unable to delete the report after archiving. We have been able to work around this issue for now, but it would be nice if it could be solved in your code :).

We're running the code with:

docker run --privileged --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io --config ./test/performance/sitespeed.config.json http://sitespeed.io

and we use the following configuration file:

{
  "resultBaseDir": ".",
  "outputFolder": "./reports/performance",
  "html": {
    "showAllWaterfallSummary": true
  },
  "metrics": {
    "filterList": true
  },
  "summary": true,
  "summaryDetail": true,
  "mobile": true,
  "budget": {
    "configPath": "./test/performance/performance-budget.json",
    "output": "junit"
  }
}

[soulgalore]

Hey @ronderksen
yes I'm aware of but not sure the best way to solve it, any input are appreciated! Before we released 4.0 we tried out setting up specific user inside of the Docker container to run sitespeed.io. That worked fine, we needed to add sudo so that the user could run the tc command and it worked.

The problem however was that the user inside the container rarely had the permissions of writing the files outside the container. I know you "should" setup a specific use inside of the Docker container but I'm lost with best practices on how to make sure that user still can write files outside the container.

Best
Peter

[weigo]

Hi,

i found this (referenced from https://github.com/docker/docker/issues/22258):

https://github.com/schmidigital/permission-fix

Perhaps this can be used as an approach to fix the issue.

Regards,

Dirk

[beenanner]

Or I think you can start the docker engine up with --userns-remap and map it a known user. Either way I think those are custom per user.

[weigo]

That option could be probably used, but seems to have an issue:
https://github.com/docker/docker/issues/27548
I'll give it a try since i 'suffer' from the same problem...

[ronderksen]

We have been able to work around this issue by using this extra line of code. It's not optimal, but it works :).

docker run --privileged --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io --config ./test/performance/sitespeed.config.json https://www.sitespeed.io
test -d reports && docker run --privileged --rm -v "$(pwd)":/sitespeed.io --entrypoint chown $SITESPEED_IMAGE -R `id -u`:`id -g` reports

[soulgalore]

Now when Chrome needs to run with no-sandbox there's no reason to keep privileged mode. Then we can setup a user, give the user sudo rights (running tc etc) and then see if we find the best way to make it possible to write to the volume.

[maikelwever]

A workaround that works for me, is to add the following at the bottom of docker/scripts/start.sh:

USERID=$(stat -c "%u" /sitespeed.io)
GROUPID=$(stat -c "%g" /sitespeed.io)
chown -R $USERID:$GROUPID /sitespeed.io

It's ugly but it works. I also don't use the --privileged flag since for me it doesn't seem to be needed.

[fholzer]

docker run supports a --user flag. But at the moment this causes some issues because some components used in the docker image don't like to be run as a user that technically doesn't exist inside the container. Generally this is not an issue, that is if you don't run any programs that insist the user exists.

For testing I used docker run --rm -ti -u 1000:1000 -v $(pwd)/results:/sitespeed.io/sitespeed-result sitespeedio/sitespeed.io:8.5.1 -n 1 http://sitespeed.io/ (1000 being the uid and gid that should own the report. There's some issue with start.sh's chromeSetup function (sudo not possible. dbus-launch error output). But even though there's some issues it looks like the test actually was successful, and is owned by the correct uig/gid.

[soulgalore]

Hi @fholzer I've missed to add a comment here before that's also relevant: at the moment Github Actions only support root user support to the file system, so for example if we want to feed a budget file like in https://www.sitespeed.io/documentation/sitespeed.io/continuous-integration/#github-actions that only works as long as we keep running as root. I guess one way to fix it is to create a user in the container (that has sudo rights) and then make it possible to choose, or is there a smarter way to do it?

Best
Peter

[fholzer]

Hi,

I wasn't aware this was about Github Actions. Either way, if you want to use a feature that requires root (not sure if running tests on actual mobiles requires root) then you won't be able to use docker run's --user flag.
Regarding start.sh's chromeSetup function I mentioned in my previous port: seems that may no longer be necessary since Chrome 60, as it contains a fix for that. Though I'd like to test this before suggesting a change. Though first I need to sort random VM freezes related to sitespeed in our setup.

Cheers,
Ferdinand

[soulgalore]

Ah cool, yeah it was added ages ago. Let me try to remove it also, I can just push it to our test server.

Let me know how it works out for you!
Best
Peter