k8s-csi-s3
k8s-csi-s3 copied to clipboard
BUG: volume mounted as root:root despite options are set otherwise
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
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
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.
@pasztorl can you take another look? this really looks like a bug to me. Such that geesefs is unusable for nonroot users
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"