Wrong ownership for some files in the docker image
Since that version of memgraph-platform image
memgraph/memgraph-platform 4175e85fe222 7 weeks ago 4.27GB
I cannot pull new images with userns-remap enabled for my docker-daemon (there is a need to Isolate containers with a user namespace):
docker.io/library/ubuntu:latest
latest: Pulling from memgraph/memgraph-platform
918547b94326: Already exists
f815fa9e14e8: Pull complete
6b482b77e73b: Pull complete
88cf2268c327: Pull complete
8732ff3dcc30: Extracting [==================================================>] 203.1MB/203.1MB
577cf9a29f74: Download complete
70c869c750eb: Download complete
c24bc4875209: Download complete
085adf99c4c7: Download complete
bf3ca2dacec8: Download complete
30606883fc65: Download complete
785edee73992: Download complete
b439c9539bc9: Download complete
2e342eec9491: Download complete
64b9a94c8a58: Download complete
78859b243ab6: Download complete
07e024a86f7b: Download complete
4f4fb700ef54: Download complete
failed to register layer: Container ID 718322462 cannot be mapped to a host ID
Indeed, It's unlikely for 718322462 to be within ID ranges set in /etc/subuid and /etc/subgid files, whenever someone configures userns-remap. I tried to extend them and perform such search for files that have too high uid/gid:
$ docker run --rm -it memgraph/memgraph-platform bash
root@fa41dca61e14:/# find / \( -type f -or -type d \) -exec \
bash -c '[ $(expr $(stat -c "%u + %g" "$0") ) -ge 131069 ] && ls -dln "$0"' {} \;
-rw-r--r-- 1 718322462 454177323 1518 May 18 16:04 /lab/node_modules/buffer-equal-constant-time/LICENSE.txt
-rw-r--r-- 1 718322462 454177323 26 May 18 16:04 /lab/node_modules/buffer-equal-constant-time/.npmignore
-rw-r--r-- 1 718322462 454177323 484 May 18 16:04 /lab/node_modules/buffer-equal-constant-time/package.json
-rw-r--r-- 1 718322462 454177323 45 May 18 16:04 /lab/node_modules/buffer-equal-constant-time/.travis.yml
-rw-r--r-- 1 718322462 454177323 1045 May 18 16:04 /lab/node_modules/buffer-equal-constant-time/index.js
-rw-r--r-- 1 718322462 454177323 1101 May 18 16:04 /lab/node_modules/buffer-equal-constant-time/README.md
-rw-r--r-- 1 718322462 454177323 1013 May 18 16:04 /lab/node_modules/buffer-equal-constant-time/test.js
I'd like to ask to fix owner/group for those files (and some other at least under /lab/node_modules/) before-or-at the docker-build, otherwise, you see,
- everyone will face pull-fail when
userns-remapenabled (and ranges specified atsubuid/subgidnot cover too high IDs), - ~those files would be inaccessible to non-root processes~ (UPD. Well, they're world-Readable, and their parent dir is everyone-eXecutable).
Also that would agree with a good practice to keep the stuff in order. TIA!
UPD. I suggest COPY --chown=0:0 <...> at least at https://github.com/memgraph/memgraph-platform/blob/main/Dockerfile#L98 as good enough workaround, if you wish to fix this at docker-build stage instead of at the files origin (where they are copied from).
Hi @vpag and thank you for reporting this! This is definitely something we need to fix and thank you for giving us suggestions too. Will keep you posted on the issue. Btw. what are you working on with Memgraph?
Hi @katarinasupe This still isn't fixed? Looks like you are using an outdated library that has been superseeded by core as well? I've been tasked with evaluating Memgraph compared to Neo4j and we run unprivileged containers.
This is really vexing. This is a rather low hanging fruit and a work-around has been provided. for simply changing one line in a build-pipeline 6 months is really a long time. It is anything but trust inspiring.
Hi @teatreeoilchocolate, I agree with you and apologize for making you wait this long. The happy news is that we are working on something new to make deployment easier for any developer, and that's why we didn't focus on this issue. Does this issue block your work?
Not a blocking issue. After I recovered from being flabbergasted by this ticket, its timeline, the triage of it, the minimal effort(especially considering that the fix is already provided) combined with the big impact and it not moving, the community dev that debugged the problem being ignored and being fed a boiler plate response(would've been ok if it weren't for the garbage-chute) for their effort in combination with throwing this ticket down the garbage-chute, I immediately moved to another graphdb after having penned my disbelieve in the previous response.
And to be clear, this is not entitlement speaking. I appreciate free software I can run to cut my teeth on to grow. I appreciate the fact that being a dev in a public environment is stressful. I appreciate the minutea of working in a volatile environment with changing and competing priorities. I report bugs in software I use. I sometimes even help to debug them where I can if asked. I have also not a problem with working around bugs and living with the ones I cannot work around. But this,considering that it was triaged S2-I2(one short of ' the house is burning') last month with it not moving at all(considering that it is low effort) and touching on security in a software that houses data and may at one point even house mine, leaves me speechless. Especially since the new features must in fact be so awesome and big and heavy, that there was no time to address an issue concerning security for certain setups of users of your software within the last 6 months.
Thank you for your feedback, @teatreeoilchocolate. It will help us learn how to improve in the future. We recently changed our prioritization system and still have some tweaks to do. We will update the priorities in the community bugs and incremental features project. In the future, if you notice these things and you feel like something is urgent and we should make more effort, or if you have questions, don't hesitate to contact us by booking an office hours call. We are also quite active on Discord to help the community.
Let's revisit this with the new Memgraph Platform setup cc @MarkoBarisic @gitbuda