NFSv4 with Kerberos and no_root_squash
Subsystems (2)
Hi folks,
Not long ago I managed to get NFSv4 to work together with Kerberos (gss/ krb5i or gss/krb5p), but apparently there's a limitation. It has to do with exports that include the "no_root_squash" option and then attempting to allow root on the clients to write to them; this always results in a "Permission denied" error.
Is there a solution for this, or a workaround?
For me this is important, because one of the sites I maintain uses NFS for home directories and the workstations have an elaborate logout script in /etc/X11/Xreset.d/ that runs as root (the script contains many sudo commands to make changes to the user's home directories). Therefore, one solution would be to avoid running the logout script as root, but AFAIK that's not possible.
Thanks,
Jaap
Quoted 8 lines · Jaap
Hi folks,
Not long ago I managed to get NFSv4 to work together with Kerberos (gss/ krb5i or gss/krb5p), but apparently there's a limitation. It has to do with exports that include the "
no_root_squash" option and then attempting to allow root on the clients to write to them; this always results in a "Permission denied" error.
Quoted 8 lines
Is there a solution for this, or a workaround?
For me this is important, because one of the sites I maintain uses NFS for home directories and the workstations have an elaborate logout script in
/etc/X11/Xreset.d/that runs as root (the script contains many sudo commands to make changes to the user's home directories). Therefore, one solution would be to avoid running the logout script as root, but AFAIK that's not possible.
You may want to look at "Credentials for UID 0" in the rpc.gssd man page?
--b.
Quoted 2 lines · J. Bruce Fields
You may want to look at "Credentials for UID 0" in the rpc.gssd man page?
If you mean that I should run rpc.gssd with the "-n" option, in that case I still get "Permission denied" when attempting to write to one of the "no_root_squash" exports as root. I even tried using the machine credentials "root/<hostname>@<REALM>" instead of "host/..." , but to no avail.
Thanks anyway,
Jaap
Quoted 8 lines · Jaap
Quoted 2 lines · J. Bruce Fields
You may want to look at "Credentials for UID 0" in the rpc.gssd man page?
If you mean that I should run rpc.gssd with the "-n" option, in that case I still get "Permission denied" when attempting to write to one of the "
no_root_squash" exports as root.
What credentials is root using in that case?
Quoted 3 lines
I even tried using the machine
credentials "root/<hostname>@<REALM>" instead of "host/..." , but to no avail.
Right, I'd expect that to be mapped to nobody.
You can set up a one-off mapping for a given machine credential in idmapd.conf. (If you're using rpc.svcgssd. If you're using gss-proxy I think there's similar configuration in /etc/krb5.conf.)
--b.
Quoted 1 line · J. Bruce Fields
Right, I'd expect that to be mapped to nobody.
Same here. But if I export a directory that is owned by nobody.nogroup, I still can't write to it as root.
Quoted 2 lines
You can set up a one-off mapping for a given machine credential in idmapd.conf. (If you're using rpc.svcgssd. ...)
I am using rpc.svcgssd, but even if I add the following to idmapd.conf on both the server and the client (although I think it's only necessary on the server):
[Static]
root/<hostname>@<realm> = root
... I still get the same result when I try to write to one of the exports as root: Permission denied.
Quoted 2 lines
( ... If you're using gss-proxy I think there's similar configuration in
/etc/krb5.conf.)
That would be the "auth_to_local" tag in the [Realms] section. The gss- proxy project seems to be a RedHat effort to replace rpc.svcgssd. Perhaps not such a bad idea. However, I'm using Debian.
Thanks,
Jaap