On Fri, 2022-01-21 at 15:44 -0500, Ramana Venkatesh Raja wrote: > Hi, > > The mgr/nfs module manages nfs-ganesha services including their > exports [1]. It has interfaces that allow creating ganesha exports for > CephFS using `ceph nfs export create cephfs` or `ceph nfs export > apply` command, and updating exports using `ceph nfs export apply` > command. When creating an export for CephFS the mgr/nfs module > creates a FSAL ceph user with path restricted MDS caps based on the > requested export or clients' access type and the CephFS path to be > exported [2]. The export's libcephfs client ends up with read-only or > read-write MDS caps to the path being exported. > > If a ganesha export's or clients' access type is updated, then it is > expected that the ganesha server enforces the access type change > dynamically i.e., enforces the change after a SIGHUP or DBus signal > and not require a ganesha server restart. > That's a pretty big expectation. There are all sorts of settings that are not generally changeable on the fly and that require some sort of server restart. Why are restarts such a problem? Are you just concerned about having to impose a grace period? > However in the case of > exports managed by mgr/nfs module, changing the access type of a > CephFS export (or its clients) requires changing the MDS caps of the > FSAL ceph user. AFAIK this change cannot take effect without a ganesha > server restart. The alternative is to remove the existing export, and > create a new one. Both these solutions to update access of a CephFS > export are not ideal. I could think of the following solutions to > allow dynamic update of CephFS exports with the mgr/nfs module : > > a) Modify mgr/nfs module to always create a FSAL ceph user with > read-write path restricted MDS caps for CephFS exports. > > b) Add a CLI option (e.g. --fsal_ceph_user_access) to `ceph nfs nit: please don't mix dashes and underscores in option names. ;) > export create cephfs` and `ceph nfs export apply` commands that > allows setting FSAL ceph user's MDS caps access type during CephFS > export creation. Add another option to `ceph nfs export apply` command > that does not try to change the MDS caps access level of the fsal ceph > user when updating a CephFS export's access type. > > c) Add a CLI option (e.g. --fsal_ceph_user_access) to `ceph nfs > export create cephfs` and `ceph nfs export apply` commands that > allows setting FSAL ceph user's MDS caps access type during CephFS > export creation. Add a new CLI `ceph nfs export update cephfs` that > does not try to change the > to change the MDS caps access level of the fsal ceph user when > updating a CephFS export's access type. > > Option a) is the simplest, but too much of a security compromise? > Option b) and c) may confuse users and add complexity to the code. Any > other suggestions? > d) roll some special handling in libcephfs that allows you to transition an existing client's access? Then you could teach ganesha to trigger this at the right times. It's a non-trivial solution, but probably the smoothest way to achieve what you want. e) Live with restarts? I'm not sure why they're such an issue and what's driving this requirement. > Thanks, > Ramana > > [1] https://docs.ceph.com/en/latest/mgr/nfs/#export-management > [2] https://github.com/ceph/ceph/blob/v16.2.7/src/pybind/mgr/nfs/export.py#L188 > > _______________________________________________ > Dev mailing list -- dev@xxxxxxx > To unsubscribe send an email to dev-leave@xxxxxxx > -- Jeff Layton <jlayton@xxxxxxxxxx> _______________________________________________ Dev mailing list -- dev@xxxxxxx To unsubscribe send an email to dev-leave@xxxxxxx
