fix: drop privileges during docker build

[rti]

Until now, the WDQS image started as root. In the entrypoint priveleges were dropped and we switched to the "blazegraph" user. With this patch, we switch to the "blazegraph" user already during build. So the container always uses this user and does not start as root anymore.

This fixes some issues when running an interactive bash inside the container and simplifies the updater reset workaround.

https://phabricator.wikimedia.org/T362963

[lorenjohnson]

This looks good! What will be the impact on existing use of the WDQS image I wonder? Would you anticipate any permissions issue?

[rti]

This looks good! What will be the impact on existing use of the WDQS image I wonder? Would you anticipate any permissions issue?

Well, before we had this thing to fix data access rights in the entrypoint in case somebody was booting the image with a data volume populated with an image that still used the old blazegraph user AKA 666.

if [ -d /wdqs/data/ ]; then
  chown blazegraph:blazegraph -R /wdqs/data/
fi

We cannot do this anymore, because we are not root in the entrypoint with this change.

So if somebody would boot this new image with a data volume populated with an image before 9a775cc this could be a problem, because the access rights on the data do not match. But this change is already in wmde.20, wmde.18 and wmde.17 (wmde.19 missed it somehow). So coming from releases from the "deploy-era" shouldn't be a problem.

What do you think @lorenjohnson ?

[lorenjohnson]

This looks good! What will be the impact on existing use of the WDQS image I wonder? Would you anticipate any permissions issue?

Well, before we had this thing to fix data access rights in the entrypoint in case somebody was booting the image with a data volume populated with an image that still used the old blazegraph user AKA 666.

if [ -d /wdqs/data/ ]; then
  chown blazegraph:blazegraph -R /wdqs/data/
fi

We cannot do this anymore, because we are not root in the entrypoint with this change.

So if somebody would boot this new image with a data volume populated with an image before 9a775cc this could be a problem, because the access rights on the data do not match. But this change is already in wmde.20, wmde.18 and wmde.17 (wmde.19 missed it somehow). So coming from releases from the "deploy-era" shouldn't be a problem.

What do you think @lorenjohnson ?

Given that this will not breaking anything in the 1.0 WDQS then this is still a patch or minor update, and I think ok to not document further at this time.

[rti]

holding back for #782