Open vpag opened 1 year ago
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
Since that version of
memgraph-platform
imageI cannot pull new images with
userns-remap
enabled for my docker-daemon (there is a need to Isolate containers with a user namespace):Indeed, It's unlikely for
718322462
to be within ID ranges set in/etc/subuid
and/etc/subgid
files, whenever someone configuresuserns-remap
. I tried to extend them and perform such search for files that have too high uid/gid: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,userns-remap
enabled (and ranges specified atsubuid
/subgid
not cover too high IDs),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).