8:37 a.m.
This is an unfortunate side effect of the difference between NFS
semantics and POSIX semantics. The API provided by the kernel to
support NFS semantics requires special privileges.
I believe it's possible to write a library that maps open FDs to NFS
handles. This would allow you to open a file when you give out a
handle, and keep it open, mapping the handle back to the FD. The
downside of this is that you either need to keep FDs open forever (using
up your max FDs pretty quickly), or time them out, at which point you
have to send an error for that handle. This would more-or-less work for
some circumstances, but definitely not for all.
Another possibility is to run Ganesha in a user namespace. This maps
UIDs inside the namespace to non-privileged UIDs outside the namespace.
I don't know if this allows the necessary CAPs inside the namespace or
not, but it might. If it does, then you could have access via Ganesha
to the subtree inside the namespace. Again, not a 100% solution, but
maybe better than nothing.
Daniel
On 6/27/21 10:04 PM, Tom McLaughlin wrote:
Thank you both for the help!
The capabilities needed to run on FSAL_VFS are a bit of a show-stopper for me. But for
posterity let me write down my experience trying to get it to work.
Here's the crazy capsh command I came up with to get the process running with the
necessary ~5 or so capabilities (I found these listed in the source):
sudo capsh --caps="cap_dac_read_search+eip cap_dac_override=+eip cap_fowner=+eip
cap_setgid=+eip cap_setuid=+eip cap_setpcap,cap_setuid,cap_setgid+ep" --keep=1
--user=tom --addamb=cap_dac_read_search,cap_dac_override,cap_fowner,cap_setgid,cap_setuid
-- -c "/home/tom/tools/ganesha/result/bin/ganesha.nfsd -F -f ganesha.conf -L
./logs.txt -p ./ganesha.pid"
and here's my config:
NFS_KRB5 {
Active_krb5 = false;
}
NFS_CORE_PARAM {
Protocols = 4;
NFS_Port = 7777;
Rquota_Port = 7778;
Enable_RQUOTA = false;
}
NFSv4 {
RecoveryRoot = "/tmp/recovery_root";
}
EXPORT {
Export_Id = 2;
Path = /tmp/exported;
Pseudo = /tmp/exported;
Access_Type = RW;
Squash = No_Root_Squash;
Transports = "TCP";
Protocols = 4;
# SecType = none;
SecType = "sys";
FSAL {
Name = VFS;
}
}
Note that the custom recovery root and the export dirs need to exist, or it immediately
segfaults.
With this setup, the server *sort of* works. I'm able to run a `mount` command on the
same machine. If I put a file in the exported dir, I can read it in the mount. Writing to
the mount is more problematic -- if I echo some data into a file, it tends to hang for
several minutes and then sometimes succeed (such that I can read it from the exported
dir).
My dream would be to be able to run Ganesha against FSAL_VFS as a normal user inside a
Docker container, in order to share some folder that the user controls. But I can see that
at a minimum this will require running the container with special capabilities.
_______________________________________________
Support mailing list -- support(a)lists.nfs-ganesha.org
To unsubscribe send an email to support-leave(a)lists.nfs-ganesha.org