@hrefna wow, I'm amazed that choice hasn't been revisited since, unbelievable

@hrefna I'm sorry if this is a stupid question but, why in the hell do elections happen on a Tuesday instead of a Sunday?

It looks to me like a decision made on purpose to make it harder for working ppl to vote, idk

tl;dr: upgrade glibc on your servers!

Summing it up, there's a vulnerability (CVE-2024-2961) on glibc that, apparently, can be used to get RCE on servers running PHP.
It's recommended that you update glibc to a patched version.

https://security-tracker.debian.org/tracker/CVE-2024-2961
https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2024-2961

There's an upcoming talk on May 10 where the researcher will explain how it was used to hack PHP servers.

https://www.offensivecon.org/speakers/2024/charles-fol.html

#PHP #glibc #iconv

@roadriverrail @futurebird

@feditips @datavizzard I think @remindme is what you're looking for!

@silvereagle

OK, just for the record, I've found *a solution*. I don't like it and it does feel hacky, although otoh it doesn't feel too wrong.

Add an extra initContainer with busybox and chown the shared volume with the desired uid and gid. It's ugly but it works. If nobody throws a big reason why I shouldn't be doing this, I'm going to leave it like this.

Thanks for the boosts #hachyderm !

Source https://discuss.kubernetes.io/t/write-permissions-on-volume-mount-with-security-context-fsgroup-option/16524

So, let's see if #hachyderm or the further #Federation can give me a hand with some #kubernetes (#k8s).
I've got 2 containers running on the same pod. One of them (nginx) run as root and the other (app) doesn't. I'm trying to have a shared volume between the 2 using an emptyDir, but when I try to copy files on initContainer using the non-root img, I get an error telling me "Operation not permitted" when trying to chgrp the volume. Can I change the ownership of the volume? securityContext? #help