Forcegid doesn't seem to work

[superbspeed]

What happened:

Access to the SMB share is not restricted per gid:

[admin@mgmt01 fsx]$ k exec -it smb-test -n dev -- bash
groups: cannot find name for group ID 1114200513
groups: cannot find name for group ID 1114304631
I have no name!@smb-test:/$ id
uid=1114301531 gid=1114200513 groups=1114200513,1114304631
I have no name!@smb-test:/$ cd /ClincPharm/
I have no name!@smb-test:/ClincPharm$ ls -la
total 0
drwxrwx--- 2 root 1114304632  0 Oct  2 19:36 .
drwxr-xr-x 1 root root       47 Oct 17 10:25 ..
drwxrwx--- 2 root 1114304632  0 Oct  2 19:34 Restricted
I have no name!@smb-test:/ClincPharm$ cd Restricted/
I have no name!@smb-test:/ClincPharm/Restricted$ touch file.txt
I have no name!@smb-test:/ClincPharm/Restricted$ ls -la
total 0
drwxrwx--- 2 root 1114304632 0 Oct 17 10:38 .
drwxrwx--- 2 root 1114304632 0 Oct  2 19:36 ..
-rwxrwx--- 1 root 1114304632 0 Oct 17 10:38 file.txt

What you expected to happen: Mount options gid and forcegid to work by restricting access only to users in the gid. In this case the user should have been denied access to the share.

How to reproduce it:

apiVersion: v1
kind: PersistentVolume
metadata:
  annotations:
    pv.kubernetes.io/provisioned-by: smb.csi.k8s.io
  name: pv-smb-bu-clinpharm
spec:
  capacity:
    storage: 100Gi
  accessModes:
    - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain
  storageClassName: smb
  mountOptions:
    - dir_mode=0770
    - file_mode=0770
    - gid=1114304632
    - forcegid
    - noperm
    - mfsymlinks
    - cache=strict
    - noserverino  
  csi:
    driver: smb.csi.k8s.io
    volumeHandle: datastore.mydomain.com/BU/ClincPharm
    volumeAttributes:
      source: //datastore.mydomain.com/BU/ClincPharm
    nodeStageSecretRef:
      name: smbcreds
      namespace: default
	  
---
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: fsx-windows-clinpharm
  namespace: dev
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 100Gi
  volumeName: pv-smb-bu-clinpharm
  storageClassName: smb

---
apiVersion: v1
kind: Pod
metadata:
  name: smb-test
  namespace: dev
spec:
  securityContext:
    runAsUser: 1114301531
    runAsGroup: 1114200513
    supplementalGroups:
    - 1114304631
  volumes:
  - name: clinph
    persistentVolumeClaim:
      claimName: fsx-windows-clinpharm
  containers:
    - name: example-container
      image: ubuntu:jammy
      command: ["sleep"]
      args: ["1000"]
      volumeMounts:
      - name: clinph
        mountPath: /ClincPharm
  restartPolicy: Always

Anything else we need to know?: The share itself is restricted to the group and the account used in PV (smbcreds) is a member of the group.

Environment:

• CSI Driver version: v1.16.0
• Kubernetes version: v1.26
• OS (pod): Ubuntu 22.04
• Kernel (pod): 5.10.225-213.878.amzn2.x86_64
• Others: Running on AWS EKS

[andyzhangx]

that seems to be the cifs driver issue

[superbspeed]

Can you please tell me how I can troubleshoot this further? I have tried this so far:

• Mounting the share on the EKS node directly, it worked as expected by not denying access to the user as it was not in the group
• Reviewed the smb node as well as controller pod logs and found no indications of any issues

[tcederquist]

I'm interested in this case as well. I've reviewed the code and not able to see where it passes options to the cifs driver. Could anyone help me locate where it transfer the options to the underlying driver? I'm not seeing anything other than username/password being passed through the csi driver to the cifs mount. Perhaps it's only passing specific parameters down and gid isn't one of them?

[andyzhangx]

I'm interested in this case as well. I've reviewed the code and not able to see where it passes options to the cifs driver. Could anyone help me locate where it transfer the options to the underlying driver? I'm not seeing anything other than username/password being passed through the csi driver to the cifs mount. Perhaps it's only passing specific parameters down and gid isn't one of them?

@tcederquist you only need to pass the new mount option into mountOptions field in pv, and you could check the csi driver logs on the node to verify.

[superbspeed]

I was able to resolve this. I didn't realize I had noperm option in there. Removing it fixed it for me. 😄