Supporting gid as mount option

[gnufied]

This keeps coming back and so far CSI has stayed away from how volume permissions are applied to CSI volume and leaving this to CO.

But in Kubernetes - we have found a use case which calls for some clarification and possibly a spec change in CSI.

The problem is - certain CSI drivers apply gid as a mount option during NodeStage or NodePublish and CO needs to pass gid of pod/workload to the CSI driver, so as CSI driver can mount volume with appropriate mount option during nodestage/nodepublish.

Why can't we use existing mount flags for this?

The reason we can't use existing mount flags for this is because - CO does not know how to format/compose the mount option string. Some CSI driver may require this as -gid=<gid> and others in different format.

Alternatively we can break boundaries of CO and CSI driver and pass gid as some sort of extended volume attributes on nodestage/nodepublish and driver is free to use the gid as however it wants.

A third option is to make it explicit option in CSI spec. This is the option we would like to explore via this issue.

cc @jdef @saad-ali @msau42 @jsafrane

[jdef]

Can you list one or two driver examples and maybe some pseudo config that further explains how the status quo doesn't meet the need?

…

On Fri, Sep 18, 2020, 12:01 PM Hemant Kumar ***@***.***> wrote: This keeps coming back and so far CSI has stayed away from how volume permissions are applied to CSI volume and leaving this to CO. But in Kubernetes - we have found a use case which calls for some clarification and possibly a spec change in CSI. The problem is - certain CSI drivers apply gid as a mount option during NodeStage or NodePublish and CO needs to pass gid of pod/workload to the CSI driver, so as CSI driver can mount volume with appropriate mount option during nodestage/nodepublish. Why can't we use existing mount flags for this? The reason we can't use existing mount flags for this is because - CO does not know how to format/compose the mount option string. Some CSI driver may require this as -gid=<gid> and others in different format. Alternatively we can break boundaries of CO and CSI driver and pass gid as some sort of extended volume attributes on nodestage/nodepublish and driver is free to use the gid as however it wants. cc @jdef <https://github.com/jdef> @saad-ali <https://github.com/saad-ali> — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#449>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAR5KLH6WKPJECDSV2JIDATSGN735ANCNFSM4RSF5OWA> .

[gnufied]

The driver example will be something like - azurefile which requires mount option to be specified via - mount -o gid=<>. Some other drivers that support mount time uid/gid options is - sshfs (https://wiki.archlinux.org/index.php/SSHFS), which accepts mount option as mount -o idmap . there could be other fuse based drivers capable of doing this mapping.

The reason status-quo does not meet the need is because - CO can't pass these flags as mount options. Because for mount options to work, CO must know how to format the mount option string, but since each driver can have potentially its own format - CO can't specify these flags as mount options and hence gid (and may be uid) must be supplied separately to nodeStage and NodePublish RPC calls.

[saad-ali]

Meeting Notes from CSI Meeting Oct-14-2020

@bswartz - Windows has a concept of ACLs on files.
@jsafrane - Mounting windows share in to linux -- but at mount time you must choose mapping from Windows to Linux. We need volume to appear as if all files have GID. How to pass this info from CO to SP. If you can please mount all files with GID. Some capabilities around this? What would the best approach be?
@msau42 - 2 different plugins may use 2 different mount options to do GID mapping, so we can't assume all plugins support mount options flag.
@jsafrane - yep. Goal should be in the end not have to change existing drivers, just let windows drivers advertise a new capability.
@msau42 - for SP on linux only, is there a generic mount option they can use to do this?
@jsafrane - Not possible for XFS, maybe for NFS.
@bswartz - Are we proposing a new field at StageVolume -- extra ACL info? If dual windows/linux volume?
@msau42 - Linux drivers could optionally take advantage of this too. Must be a capability.
@bswartz - goal is to let CO pass what to SP?
@jsafrane - problem is k8s just need 1 GID number (all files must be fully accessible to that GID). No windows equivalent of that.
@bswartz - the container running on windows has an identity and permissions, you should be able to allow and deny access.
@msau42 - my understanding is no permissions support on k8s for windows yet. Would need to sync with @ddebroy
@bswartz - I foresee issues when we get around to a windows driver.
@msau42 - Jing has been doing FS compatibility.
@bswartz - Cifs windows file share -- all access control is built in to protocol, client/server need to do their thing to get access.
@jsafrane - That's done during mount.
@bswartz - What if user ID doesn't have access cause it was created as a Linux volume now mapped to Windows. User name may not have access to windows.
@jsafrane - When mount succeeds files will have correct permissions?
@bswartz - I'm still nervous about how this will work when we do Windows drivers.
@jsafrane - k8s is user or storage plugin is user, and it has secrets to mount and create volume, etc.
@msau42 - Would be good to sync with @ddebroy and Jing on interoperability work they have been doing to help shape this API.
@jsafrane - On the linux side, I think we have to provide the mount option, otherwise volume is not accessible.
@msau42 - we can focus on Linux, but should have a basic understanding of Windows, so we don't paint ourselves in to a corner
@bswartz - +1, let's make sure the API is flexible enough to handle both.
@jsafrane - I can't help much with Windows, so we'll pull in @ddebroy and Jing. General approach: "capability + field" right approach? What do other COs want/need?
@msau42 - seems reasonable to have a new capability.

Action item:

• Pull in pull in @ddebroy and Jing and ensure this is flexible enough for Windows.

[mkimuram]

@gnufied

Is "idmapped mounts" feature merged to Linux kernel 5.12 related to this?
It looks that it gives us a way to map uids and gids on mount time for any filesystems on Linux.
(I first thought that the feature will be utilized by container runtime on mapping local filesystem to container, but we would be able to do it on node stage/publish as discussed here.)