0

I'm running the following command inside a container as an ordinary, non-root user

gcsfuse --foreground --debug_fuse --debug_fs --debug_gcs --debug_http my-bucket /data

and it works locally when I start the container with --priviliged and that's fine.

But the same doesn't work on Cloud Run (when using the 2nd generation preview execution environment). I get the following error:

2022-05-13 12:08:41.547 CEST gcs: 2022/05/13 10:08:41.546642 Req 0x1: -> ListObjects("") (46.897367ms): OK
2022-05-13 12:08:41.551 CEST /usr/bin/fusermount: failed to open /dev/fuse: Permission denied
2022-05-13 12:08:41.551 CEST mountWithArgs: mountWithConn: Mount: mount: running /usr/bin/fusermount: exit status 1

All other debug log lines, HTTP, GCS, etc. show everything works.

I create my user like this in my Dockerfile

RUN useradd -lmU joe\
  && mkdir -p /data \
  && chown -R joe:joe /data
USER joe

The docs says that I should run gcsfuse as the user who will be using the file system, not as root, but it doesn't work. Any idea what I'm doing wrong?

Kohányi Róbert
  • 103
  • 4
  • Have a look at this [answer](https://stackoverflow.com/a/70430026/15803365). The poster of the question (https://stackoverflow.com/questions/70407189/unable-to-mount-bucket-with-gcsfuse-on-cloud-run) was facing a similar error message and was not able to mount the bucket with gcsfuse on Cloud Run. – Priyashree Bhadra May 17 '22 at 05:39
  • @PriyashreeBhadra Thanks! I've seen that question/answer, but I think using `777` defeats the purpose. With `root`, for me everything works, but the docs promotes that one should not use `root`, so .. IMHO this is suboptimal. (The purpose being following a *security first* approach when dealing containers.) Maybe this isn't possible at all, but then that's the answer! :) – Kohányi Róbert May 17 '22 at 14:30
  • By default, all inodes in a gcsfuse file system show up as being owned by the UID and GID of the gcsfuse process itself, i.e. the user who mounted the file system. 644 and 755 are the default permissions for all file and directory inodes in a gcsfuse file system. Changing inode mode (using chmod(2) or similar) is unsupported, and changes are silently ignored. – Priyashree Bhadra May 19 '22 at 06:30
  • When you mount your storage bucket using gcsfuse, the fuse kernel layer restricts file system access to the user who mounted the file system. If you like to provide access to other users, you can override this behavior with the allow_other mount option along with the --uid and --gid flags. However, keep in mind that this may have security implications. See [here](https://github.com/googlecloudplatform/gcsfuse/blob/master/docs/semantics.md#inodes) for documentation. – Priyashree Bhadra May 19 '22 at 06:31
  • `a gcsfuse file system show up as being owned by the UID and GID of the gcsfuse process itself` Which is exactly what I want. Start `gcsfuse` as `joe`, which doesn't work currently. `If you like to provide access to other users, you can override this behavior with the allow_other mount` But I don't want to, for the exact reason you mention that this have security implications. I'm starting to see, that this issue rather a Cloud Run environment problem, than a `gcsfuse` one, however as Cloud Run users are potentially the ones who could leverage this the most I'll keep this question open. – Kohányi Róbert May 19 '22 at 09:16
  • I think I have seen a lot of people use services other than Cloud Run with gcsfuse ( for eg like VM instance). As per my understanding, this question seems to be a gcsfuse permission question rather than Cloud Run to me, but yes its valid if a person doesn't want to do chmod with 777/ 666 permissions or use allow_other. I came across this GitHub [issue comment](https://github.com/GoogleCloudPlatform/gcsfuse/issues/236#issuecomment-361956965) which seems fair. Can you try adding yourself to a fuse group and change the group to fuse in the /dev/fuse device. Let me know if that's feasible for u – Priyashree Bhadra May 19 '22 at 11:58
  • `/dev/fuse` is only available when the container actually starts up so my `joe` user without `root` cannot change ownership, and since the device is owned by `root:root` there's nothing I can do about it. I did try to create the `fuse` group and add my user to it, but ... it didn't seem to work. I'll try whenever I have the time, ... but! Things work locally with the `--priviliged` flag passed to `docker run` eventhough the device is owned by `root:root`. In the GitHub issue comment it's said that they change *the group to fuse in the `/dev/fuse` device*. They must execute under `root` then. – Kohányi Róbert May 19 '22 at 18:45
  • *They must execute under root then.* Which is then a solution *kind of*, although hacky a bit. Thanks for mentioning this GitHub issue, I've subscribed! – Kohányi Róbert May 19 '22 at 18:46

1 Answers1

1

For the community in search for an answer to this question :

As per this answer, adding the -file-mode=777 -dir-mode=777 together with gcsfuse command in gcsfuse.sh to enable read/write inside the mounted directory of GCS bucket should be one option but since Kohányi Róbert confirmed that it does not serve the purpose for security reasons. I dig further and I found this really helpful information:

  • By default, all inodes in a gcsfuse file system show up as being owned by the UID and GID of the gcsfuse process itself, i.e. the user who mounted the file system. 644 and 755 are the default permissions for all file and directory inodes in a gcsfuse file system. Changing inode mode (using chmod(2) or similar) is unsupported, and changes are silently ignored.

  • When you mount your storage bucket using gcsfuse, the fuse kernel layer restricts file system access to the user who mounted the file system. If you like to provide access to other users, you can override this behavior with the allow_other mount option along with the --uid and --gid flags. However, keep in mind that this may have security implications. See here for documentation

  • If a person doesn't want to do chmod with 777/ 666 permissions or use allow_other he can try adding himself to a fuse group and change the group to fuse in the /dev/fuse device. I came across this GitHub issue comment which seems fair. Things work locally with the --privileged flag passed to docker run even though the device is owned by root:root. In the GitHub issue comment it's said that they change the group to fuse in the /dev/fuse device. They must execute under root then and that could be a solution for all the users who don’t want to go through 777/ allow_other/ --uid,--gid, 666 hacks.

Priyashree Bhadra
  • 150
  • 7