NFS3+KRB5 question
Subsystems (2)
Hello list.
I am facing a strange behaviour here with a test NFS3+KRB5 setup. I am currently testing NFS4+KRB5 and everything seems to work ok.
#NFS4 export snippet/srv/nfs4 *(sec=krb5,rw,async,fsid=0,insecure,crossmnt,no_subtree_check) /srv/nfs4/media *(sec=krb5,rw,async,insecure,crossmnt,no_subtree_check)
Both the server and client linux machine are running nfs-utils 1.1.2.
I can mount these exports with.
mount -t nfs4 -osec=krb5 servername:/ /mnt
Now I tried the same with an NFS3 export.
#NFS3 export snippet/var/media 192.168.0.0/24(sec=krb5:krb5i:krb5p:sys,rw,async,insecure,no_subtree_check)
If I try to mount this export form my client it works
mount -osec=krb5 servername:/var/media /mnt
I can see that rpc.gssd on the client is doing its work fetching a ticket etc....
But as you can see i still have sec=...:sys in this export line.
If I remove sys from sec I can NO LONGER mount this share from my linux client.
Although I see a authenticated line in the server logs several times, the mount does not succeed.
Furthermore the rpc.gssd daemon on the client does not do anything in this case (I let it run in foreground to check it).
As soon as I add sec=...:sys to the export, mounting via -osec=krb5 works again and I can also see rpc.gssd doing its work.
For testing purposes I tried to mount the same export from a mac client (leopard) and this worked with and without the sec=sys.
So my question. Do you still need to have sec=sys in your exports even if you just want to mount them via kerberos or is this a bug? The server is running kernel version 2.6.24.2 and the linux client 2.6.25-rc2. I also tried to mount export from the server itself but it failed the same way.
Kind regards,
Michael
Quoted 41 lines · Michael Guntsche
Hello list.
I am facing a strange behaviour here with a test NFS3+KRB5 setup. I am currently testing NFS4+KRB5 and everything seems to work ok.
#NFS4 export snippet
/srv/nfs4*(sec=krb5,rw,async,fsid=0,insecure,crossmnt,no_subtree_check)/srv/nfs4/media*(sec=krb5,rw,async,insecure,crossmnt,no_subtree_check)Both the server and client linux machine are running nfs-utils 1.1.2.
I can mount these exports with.
mount -t nfs4 -osec=krb5 servername:/ /mnt
Now I tried the same with an NFS3 export.
#NFS3 export snippet
/var/media192.168.0.0/24(sec=krb5:krb5i:krb5p:sys,rw,async,insecure,no_subtree_check)If I try to mount this export form my client it works
mount -osec=krb5 servername:/var/media /mnt
I can see that rpc.gssd on the client is doing its work fetching a ticket etc....
But as you can see i still have sec=...:sys in this export line.If I remove sys from sec I can NO LONGER mount this share from my linux client.
Although I see a authenticated line in the server logs several times, the mount does not succeed.
Furthermore the rpc.gssd daemon on the client does not do anything in this case (I let it run in foreground to check it).
As soon as I add sec=...:sys to the export, mounting via -osec=krb5 works again and I can also see rpc.gssd doing its work.For testing purposes I tried to mount the same export from a mac client (leopard) and this worked with and without the sec=sys.
Quoted 8 lines
So my question. Do you still need to have sec=sys in your exports even if you just want to mount them via kerberos or is this a bug? The server is running kernel version 2.6.24.2 and the linux client 2.6.25-rc2. I also tried to mount export from the server itself but it failed the same way.
Kind regards,
Michael
AFAICS I experience the same behavior[#]. Wile mounting a fs with sec=krb5i:krb5p,rw,sec=sys,ro works, disabling the sec=sys option returns an EACCES to the mount syscall (for binary mount as well as text based mount). And of course the rest is working correctly, I indeed have write enabled if with krb5i.
Looks like the client does a FSINFO call with AUTH_UNIX credentials instead of using machine credentials, which is rejected by the server.
[#] Kernel is debian's 2.6.24-1 on both sides, and nfs-utils' version is 1:1.1.1-14
A message that is not in the archive (sent off-list or not yet received): 20080401123643.GA18475-Gn1em/[email protected]
Quoted 8 lines · Quentin Godfroy
AFAICS I experience the same behavior[#]. Wile mounting a fs with sec=krb5i:krb5p,rw,sec=sys,ro works, disabling the sec=sys option returns an EACCES to the mount syscall (for binary mount as well as text based mount). And of course the rest is working correctly, I indeed have write enabled if with krb5i.
Looks like the client does a FSINFO call with
AUTH_UNIXcredentials instead of using machine credentials, which is rejected by the server.
By the way, I would like to know why does this call is rejected at the NFS layer with a NFS3ERR_ACCES instead of being rejected at the RPC layer with AUTH_TOOWEAK in a rejected_reply struct ? I would expect more an NFS3ERR_ACCES when the filehandle is outside an export (with subtree_checking enabled) or when the client is not in the list of exported filesystems.
Maybe the answer is that the RPC layer has large parts of it which are unadequate with current needs and that either the server does not answer at all (and close the underlying connection) or returns accepted_reply structures with SUCCESS and delegate error management to the upper level.
Quoted 51 lines · Quentin Godfroy
Quoted 41 lines · Michael Guntsche
Hello list.
I am facing a strange behaviour here with a test NFS3+KRB5 setup. I am currently testing NFS4+KRB5 and everything seems to work ok.
#NFS4 export snippet
/srv/nfs4*(sec=krb5,rw,async,fsid=0,insecure,crossmnt,no_subtree_check)/srv/nfs4/media*(sec=krb5,rw,async,insecure,crossmnt,no_subtree_check)Both the server and client linux machine are running nfs-utils 1.1.2.
I can mount these exports with.
mount -t nfs4 -osec=krb5 servername:/ /mnt
Now I tried the same with an NFS3 export.
#NFS3 export snippet
/var/media192.168.0.0/24(sec=krb5:krb5i:krb5p:sys,rw,async,insecure,no_subtree_check)If I try to mount this export form my client it works
mount -osec=krb5 servername:/var/media /mnt
I can see that rpc.gssd on the client is doing its work fetching a ticket etc....
But as you can see i still have sec=...:sys in this export line.If I remove sys from sec I can NO LONGER mount this share from my linux client.
Although I see a authenticated line in the server logs several times, the mount does not succeed.
Furthermore the rpc.gssd daemon on the client does not do anything in this case (I let it run in foreground to check it).
As soon as I add sec=...:sys to the export, mounting via -osec=krb5 works again and I can also see rpc.gssd doing its work.For testing purposes I tried to mount the same export from a mac client (leopard) and this worked with and without the sec=sys.
Quoted 8 lines
So my question. Do you still need to have sec=sys in your exports even if you just want to mount them via kerberos or is this a bug? The server is running kernel version 2.6.24.2 and the linux client 2.6.25-rc2. I also tried to mount export from the server itself but it failed the same way.
Kind regards,
Michael
Quoted 8 lines
AFAICS I experience the same behavior[#]. Wile mounting a fs with sec=krb5i:krb5p,rw,sec=sys,ro works, disabling the sec=sys option returns an EACCES to the mount syscall (for binary mount as well as text based mount). And of course the rest is working correctly, I indeed have write enabled if with krb5i.
Looks like the client does a FSINFO call with
AUTH_UNIXcredentials instead of using machine credentials, which is rejected by the server.
The client here is within its rights, and the server is wrong; see:
http://www.ietf.org/rfc/rfc2623.txt
(especially 2.3.2, "NFS Procedures Used at Mount Time"). The kernel changes on the server side should not be too difficult after the export changes we made a few versions ago.
--b.
Quoted 7 lines
[#] Kernel is debian's 2.6.24-1 on both sides, and nfs-utils' version is 1:1.1.1-14
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 9 lines · J. Bruce Fields
Quoted 8 lines
AFAICS I experience the same behavior[#]. Wile mounting a fs with sec=krb5i:krb5p,rw,sec=sys,ro works, disabling the sec=sys option returns an EACCES to the mount syscall (for binary mount as well as text based mount). And of course the rest is working correctly, I indeed have write enabled if with krb5i.
Looks like the client does a FSINFO call with
AUTH_UNIXcredentials instead of using machine credentials, which is rejected by the server.
Quoted 7 lines
The client here is within its rights, and the server is wrong; see:
http://www.ietf.org/rfc/rfc2623.txt(especially 2.3.2, "NFS Procedures Used at Mount Time"). The kernel changes on the server side should not be too difficult after the export changes we made a few versions ago.
The server is indeed wrong to reject the fsinfo call with only AUTH_SYS credentials (and the rfc does not mandate it to accept it as far as i can see), but the client could wait a session for machine credentials before doing the call, since administrative credentials are available.
Quoted 7 lines · J. Bruce Fields
The client here is within its rights, and the server is wrong; see:
http://www.ietf.org/rfc/rfc2623.txt(especially 2.3.2, "NFS Procedures Used at Mount Time"). The kernel changes on the server side should not be too difficult after the export changes we made a few versions ago.
Hi,
Thanks for the info, is it planned to change the server part in the near future, or is this a low priority task, just curious.
Kind regards,
Michael
A message that is not in the archive (sent off-list or not yet received): 2A8F26C5-13E7-47F0-AC04-33820FF9377A-Z92qn3yYq0hWk0Htik3J/[email protected]
Quoted 11 lines · Guntsche Michael
Quoted 8 lines · J. Bruce Fields
The client here is within its rights, and the server is wrong; see:
http://www.ietf.org/rfc/rfc2623.txt(especially 2.3.2, "NFS Procedures Used at Mount Time"). The kernel changes on the server side should not be too difficult after the export
changes we made a few versions ago.
Quoted 4 lines
Hi,
Thanks for the info, is it planned to change the server part in the near future, or is this a low priority task, just curious.
It's on my todo list, but I don't know when I'm going to get to it.
--b.