k8s-csi-s3 icon indicating copy to clipboard operation
k8s-csi-s3 copied to clipboard

BUG: volume mounted as root:root despite options are set otherwise

Open schlichtanders opened this issue 1 year ago • 4 comments

Hello,

If I understood it correctly, then the geesefs csi s3 volume is mounted as root:root because the yandex csi driver is doing it so (and not because another kubernetes controller does this somehow generically for volumes).

But I set --memory-limit 1000 --dir-mode 0777 --file-mode 0644 --setuid 1000 --setgid 1000 for the options, so why is it still mounted as root?

I get permission denied EACCES errors respectively.

I am using static PV which looks like this:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: myname
spec:
  storageClassName: csi-s3
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteOnce
  claimRef:
    name: myname
    namespace: mynamespace
  csi:
    driver: ru.yandex.s3.csi
    controllerPublishSecretRef:
      name: csi-s3-secret
      namespace: kube-system
    nodePublishSecretRef:
      name: csi-s3-secret
      namespace: kube-system
    nodeStageSecretRef:
      name: csi-s3-secret
      namespace: kube-system
    volumeAttributes:
      capacity: 10Gi
      mounter: geesefs
      options: --memory-limit 1000 --dir-mode 0777 --file-mode 0644 --setuid 1000 --setgid 1000
    volumeHandle: bucket/folder

It is mounted, but the permissions are wrong. Looking at the output of mount I actually see that the groupid is wrongly configured

mymount on /home/myhome/path/to/mymount type fuse.geesefs (rw,nosuid,nodev,relatime,user_id=1000,group_id=0,default_permissions,allow_other)

doing a ls -l shows

drwxr-xr-x. 2 root       root       4096 Jul 31 15:01 mymount

schlichtanders avatar Jul 31 '24 15:07 schlichtanders

Also as I see the directory permission mask option takes no effect since your ls shows the directory permission is 766 but in your options set to 777

pasztorl avatar Aug 07 '24 06:08 pasztorl

I recreated everything (maybe there was an old storageclass still hanging around) but still get the root/root bug

the output of mount is still the same and ls -l shows now

drwxrwxrwx. 2 root       root       4096 Aug 12 08:33 mymount

Another issue pointed me to this line in the code https://github.com/yandex-cloud/k8s-csi-s3/blob/80dcfa4c021f726d67fca3e4df78e2a49a5c3e6b/pkg/mounter/geesefs.go#L97-L101 where it is indeed overwriting the uid and gid args.

schlichtanders avatar Aug 12 '24 08:08 schlichtanders

@pasztorl can you take another look? this really looks like a bug to me. Such that geesefs is unusable for nonroot users

schlichtanders avatar Aug 14 '24 13:08 schlichtanders

Unless I'm misinterpreting something, setuid/gid are meant to control the geesefs process privileges, so what we are actually looking for are the uid and gid flags, instead.

On top of that, seems that this only worked to be by also passing --enable-perms:

// [..]
    volumeAttributes:
      capacity: 5Gi
      mounter: geesefs
      options: "--memory-limit 1000 --dir-mode 0777 --file-mode 0666 --uid 1000 --setuid 1000 --gid 1000 --setgid 1000 --enable-perms"

brenodt avatar Nov 24 '24 20:11 brenodt