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
On Tue, Apr 01, 2008 at 10:51:09AM +0200, Michael Guntsche wrote:
> 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
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
On Tue, Apr 01, 2008 at 02:36:44PM +0200, Quentin Godfroy wrote:
> 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.
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.
On Tue, Apr 01, 2008 at 02:36:44PM +0200, Quentin Godfroy wrote:
> On Tue, Apr 01, 2008 at 10:51:09AM +0200, Michael Guntsche wrote:
> > 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
>
> 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.
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.
>
> [#] 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
On Tue, Apr 01, 2008 at 04:56:29PM -0400, J. Bruce Fields wrote:
> > 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.
>
> 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.
On Apr 1, 2008, at 22:56, J. Bruce Fields wrote:
> 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
On Thu, Apr 03, 2008 at 10:43:22PM +0200, Guntsche Michael wrote:
>
> On Apr 1, 2008, at 22:56, J. Bruce Fields wrote:
>> 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.
It's on my todo list, but I don't know when I'm going to get to it.
--b.