Open czka opened 1 year ago
Thanks @czka, We will discuss this issue with the team, and fix them accordingly. Closing this issue for now, since you have workaround for this.
@raj-prince IMO the ticket should stay open until the underlying issue is fixed.
I run into the same issue, as I am testing the GCS Fuse CSI Driver.
One customer is asking us to run the gcsfuse in a sidecar that uses a non-root uid/gid. I tested an arbitrary uid/gid 1000, but got the same error from gcsfuse user: unknown userid 1000
.
I believe the error comes from the code user, err := user.Current()
.
According to the discussion https://github.com/golang/go/issues/38599, the golang os/user package cannot load an arbitrary uid/gid if the uid/gid does not exist in /etc/passwd
. Unfortunately, the Kubernetes Pod Security Context only sets the uid/gid without setting the /etc/passwd
file, meaning when you do id
inside the container, you do see uid=1000 gid=1000
, but the uid/gid does not exist in the /etc/passwd
, which will cause this gcsfuse error. This also explains why after @czka gave the uid 1001 a name it worked -- because adding a name to the uid creates an entry in the /etc/passwd
file.
My solution is to do cat /etc/passwd
inside my sidecar container, then I got the following
root:x:0:0:root:/root:/sbin/nologin
nobody:x:65534:65534:nobody:/nonexistent:/sbin/nologin
nonroot:x:65532:65532:nonroot:/home/nonroot:/sbin/nologin
Then I chose 65532
nonroot uid/gid to run my sidecar container. In this case gcsfuse does not complain.
That being said, I still think it's worth it to fix the uid/gid check logic in gcsfuse because this issue prevents users from running gcsfuse binary in a container with an arbitrary uid/gid.
As mentioned in https://github.com/GoogleCloudPlatform/gcsfuse/issues/877#issuecomment-1375258143 , we will evaluate this request and update here accordingly. Till then, we suggest to use the workaround mentioned in https://github.com/GoogleCloudPlatform/gcsfuse/issues/877#issue-1516412312.
FROM docker.io/bitnami/postgresql-repmgr:15
USER root
RUN apt update
RUN install_packages curl
RUN useradd --uid 1001 --group root --no-create-home worker
USER 1001
this workaround helped me. without root
group postgres failed to start
gcsfuse (at least the latest 0.41.10 that I tried) panics in a non-root container without a user mapping.
An example with Bitnami Wordpress image:
docker pull bitnami/wordpress
docker inspect bitnami/wordpress:latest | grep -i user
:gcsfuse --debug_gcs --debug_fuse --foreground $BUCKET /mnt/gcs
:Edit: FYI, the issue is gone after giving the user
1001
a name in my Dockerfile derived from the Bitnami Wordpress image, as follows:That's only a workaround though.