Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
schlichtanders opened this issue Jul 31, 2024 · 4 comments
Open

Comments

@schlichtanders
Copy link

schlichtanders commented Jul 31, 2024

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
@pasztorl
Copy link

pasztorl commented Aug 7, 2024

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

@schlichtanders
Copy link
Author

schlichtanders commented Aug 12, 2024

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

args = append(
args,
"--setuid", "65534", // nobody. drop root privileges
"--setgid", "65534", // nogroup
)

where it is indeed overwriting the uid and gid args.

@schlichtanders schlichtanders changed the title volume mounted as root:root despite options are set otherwise BUG: volume mounted as root:root despite options are set otherwise Aug 12, 2024
@schlichtanders
Copy link
Author

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

@brenodt
Copy link

brenodt commented Nov 24, 2024

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"

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants