[NFS-Ganesha-Support] Re: Possible to run NFSv4 server as non-root user?

On Mon, 2021-06-28 at 09:07 -0700, Frank Filz wrote: > There used to be a FSAL_POSIX that kept a handle database to map handles to files by path. This was removed once we had FSAL_VFS with the open_by_handle and name_to_handle_at facilities. Unfortunately, due to the things they can do, it was deemed they needed to be privileged system calls requiring a CAP. Additionally, if nfs-ganesha is going to manage multiple users, it needs to be able to seteuid/setegid. We DO have a new capability to build without that need (it doesn't work on MacOS) and if you only needed to export files owned by a single user, it would be easy to setup Ganesha to do so, and if you needed to be able to export to non-owner users, we could probably make that work, especially if non-owners would be read-only. There are some complexities about writing to files, but I think they can be ignored in this use case (there may be some quota implications, but if an owner is allowing non-owners to expand files, the quota definitely should be assigned to the owner anyway, so doing the writes as the owner would be fine). > > But the only way to work around the CAP for open_by_handle is to add some kind of handle mapping. > > Note that as long as the file is in mdcache, even if not open, we don't need to do open_by_handle. Then the question becomes if name_to_handle_at also requires the CAP, if so, we're sunk because we have no way of creating handles (it doesn't look like name_to_handle_at requires CAP_DAC_READ_SEARCH). > > Otherwise, we might actually be OK for your use case if the clients don't need access to files that have been evicted from cache (and of course a Ganesha restart evicts everything from cache...). > > I'm not sure why we need cap_dac_override and cap_fowner - Jeff you did some looking at CAPs, do you know why? > Not right offhand. DAC_OVERRIDE allows you to override any permission bit checks, and FOWNER allows allows you to override checks for matching owner (see capabilities(7)). It's conceivable that FSAL_VFS would need those, but I'm not familiar with what it's doing specifically. Long term, it might be nice to be able to drop even more capabilities when using FSALs that don't require it. For instance, FSAL_CEPH doesn't need any of them since it's a completely synthetic backend. It can generally run with ganesha as a non-privileged user, but most deployments still run it as root.