mq-container
mq-container copied to clipboard
Running with GID != 0 fails
Due to (another) seq requirement we are not allowed to run with GID 0 in k8s.
Is there any way to do that?
I get the following error:
docker run --rm -ti -u 1001:100 -e LICENSE=accept ibmcom/mq
....
2022-07-01T11:58:46.367Z Image created: 2021-11-12T16:26:21+00:00
2022-07-01T11:58:46.367Z Image tag: ibm-mqadvanced-server-dev:9.2.4.0-r1.20211112161954.1f6d37a-amd64
2022-07-01T11:58:46.422Z MQ version: 9.2.4.0
2022-07-01T11:58:46.422Z MQ level: p924-L211105.DE
2022-07-01T11:58:46.422Z MQ license: Developer
2022-07-01T11:58:49.033Z Creating queue manager 4a59c78782b2
2022-07-01T11:58:49.033Z Starting web server
MQSeries: FFST record created in /mnt/mqm/data/errors/AMQ60.0.FDC
MQSeries: FFST record created in /mnt/mqm/data/errors/AMQ60.0.FDC
MQSeries: FFST record created in /mnt/mqm/data/errors/AMQ60.0.FDC
2022-07-01T11:58:49.138Z Error 71 creating queue manager: Permission denied attempting to access an INI file.
2022-07-01T11:58:49.139Z /opt/mqm/bin/crtmqm: exit status 71
No, the use of GID 0 is currently hard-coded in a number of places in the sample. Note that there's nothing really special about GID 0 (unlike UID 0), so it's not usually seen as a security risk. In fact, Red Hat require the use of GID 0 by default, on all containers running on Red Hat OpenShift Container Platform.
Thanks for your reply.
I would have agreed, but I asked internally and the GID != 0 requirement is coming from the NSA Hardening Guide For Kuberenetes, PDF Page 55 While I see that it contains zero reasoning for this suggestion, I'm not in the position to question that...
Fair enough. As I say, the value in the sample is hard-coded, but remember that this is just a sample, so you are free to fork and make any changes you like. I'll keep this issue open to track a future improvement.