NFSv2/3 requiring RPC_AUTH_GSS

NFSv2/3 requiring RPC_AUTH_GSS

[Benjamin Bennett]

Hi Folks,

  I've been trying the linux nfsv4 and rpcsec implementation exporting
from RHEL4 (2.6.9) to FC2 (2.6.9 & 2.6.10) and Solaris (8 & 10).

  v4 exports using gss/krb5 work from both FC2 and Solaris 10 clients.
However, for Solaris 8 I'm using v3 with gss/krb5.

  The problem I've run into with this, is that in order for the v3
client to mount (even using gss), it must be given sys/unix access too.
That pretty much rules out the nice sleep I could have gotten with all
clients using gss since they could just remount with auth_unix at will.

  To work around this, I've modified knfsd and nfs-utils to support an
additional export flag, req_gss. This flag does the same thing as the
secure/insecure flag, however it's checking the rpc auth flavor instead
of the client port. While this solution may have some issues with
RFC2623, it works well for Solaris 8 clients if you have creds at mount
time (kinit from keytab). This will not work for Linux v2/3 clients
since they use auth_unix for the fsinfo/getattr, however I do not
foresee having linux clients that support rpc_auth_gss and NOT v4, so
this isn't really an issue.

/etc/exports looks like:
/home   gss/krb5(rw,fsid=0,sync,insecure,no_subtree_check)
/home   gss/krb5i(rw,fsid=0,sync,insecure,no_subtree_check)
/home   gss/krb5p(rw,fsid=0,sync,insecure,no_subtree_check)
/home   *(req_gss,rw,fsid=0,sync,insecure,no_subtree_check)


Does anyone know of a better solution or see problems doing this (other
than incompatibility mentioned above)?


--ben



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: NFSv2/3 requiring RPC_AUTH_GSS

[Trond Myklebust]

to den 03.03.2005 Klokka 17:54 (-0500) skreiv Benjamin Bennett:
>   v4 exports using gss/krb5 work from both FC2 and Solaris 10 clients.
> However, for Solaris 8 I'm using v3 with gss/krb5.
> 
>   The problem I've run into with this, is that in order for the v3
> client to mount (even using gss), it must be given sys/unix access too.
> That pretty much rules out the nice sleep I could have gotten with all
> clients using gss since they could just remount with auth_unix at will.

Could you expand a bit on this? Is the problem that knfsd is failing to
adhere to RFC2623?
The latter says that the NFS server is supposed to accept AUTH_SYS as
being valid for fsinfo(nfsv3) or fsstat+getattr(nfsv2) on the mount
point. Is knfsd doing this?

Cheers,
  Trond
-- 
Trond Myklebust <trond.myklebust@fys.uio.no>



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: NFSv2/3 requiring RPC_AUTH_GSS

[J. Bruce Fields]

On Fri, Mar 04, 2005 at 11:03:39AM -0800, Trond Myklebust wrote:
> to den 03.03.2005 Klokka 17:54 (-0500) skreiv Benjamin Bennett:
> >   v4 exports using gss/krb5 work from both FC2 and Solaris 10 clients.
> > However, for Solaris 8 I'm using v3 with gss/krb5.
> > 
> >   The problem I've run into with this, is that in order for the v3
> > client to mount (even using gss), it must be given sys/unix access too.
> > That pretty much rules out the nice sleep I could have gotten with all
> > clients using gss since they could just remount with auth_unix at will.
> 
> Could you expand a bit on this? Is the problem that knfsd is failing to
> adhere to RFC2623?
> The latter says that the NFS server is supposed to accept AUTH_SYS as
> being valid for fsinfo(nfsv3) or fsstat+getattr(nfsv2) on the mount
> point. Is knfsd doing this?

No.

The immediate problem, though, is probably just that mountd isn't
reporting the security flavours correctly.  This shouldn't be too hard
to fix for someone with the time and inclination.

(See
http://www.citi.umich.edu/projects/nfsv4/linux/nfs-utils-patches/1.0.7-1/nfs-utils-1.0.7-06-mountd_flavors.dif
for a hack that just always returns all the krb5 flavors in the mount
reply.  All we need to do here is check the export table to figure out
which to report, and then we'll have a patch worth actually adding to
nfs-utils.)

--b.


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: NFSv2/3 requiring RPC_AUTH_GSS

[Benjamin Bennett]

On Sat, 2005-03-05 at 01:45, J. Bruce Fields wrote:
> On Fri, Mar 04, 2005 at 11:03:39AM -0800, Trond Myklebust wrote:
> > to den 03.03.2005 Klokka 17:54 (-0500) skreiv Benjamin Bennett:
> > >   v4 exports using gss/krb5 work from both FC2 and Solaris 10 clients.
> > > However, for Solaris 8 I'm using v3 with gss/krb5.
> > > 
> > >   The problem I've run into with this, is that in order for the v3
> > > client to mount (even using gss), it must be given sys/unix access too.
> > > That pretty much rules out the nice sleep I could have gotten with all
> > > clients using gss since they could just remount with auth_unix at will.
> > 
> > Could you expand a bit on this? Is the problem that knfsd is failing to
> > adhere to RFC2623?
> > The latter says that the NFS server is supposed to accept AUTH_SYS as
> > being valid for fsinfo(nfsv3) or fsstat+getattr(nfsv2) on the mount
> > point. Is knfsd doing this?
> 
> No.
> 
> The immediate problem, though, is probably just that mountd isn't
> reporting the security flavours correctly.  This shouldn't be too hard
> to fix for someone with the time and inclination.
> 
> (See
> http://www.citi.umich.edu/projects/nfsv4/linux/nfs-utils-patches/1.0.7-1/nfs-utils-1.0.7-06-mountd_flavors.dif
> for a hack that just always returns all the krb5 flavors in the mount
> reply.  All we need to do here is check the export table to figure out
> which to report, and then we'll have a patch worth actually adding to
> nfs-utils.)

I do already have that patch applied (well, the one for 1.0.6).

The problem I saw (can't require gss for v3 access) seems to be the
result of two things:

  A) mountd needs to see the v3 host in exports (or it will return
unknown host). So even though we just want to use gss, we need another
export (auth_unix) to satisfy this.

  I wrote a little code to unconditionally send back a successful mount
response with filehandle and included gss flavors. This led to the
second problem:

  B) knfsd also validates host, so we again need the same auth_unix
export as in A.


  The most simple work-around I could think of was making the auth_unix
export ro, all_squash. But that still allows auth_unix anyone to mount
and be nobody ;-)

  Whether a client is going to use gss for nfs transactions isn't
necessarily known at mount time, so we can't just have mountd ignore
hostnames when gss is going to be used.

  Is there a better way to do this than I did (violating rfc)?  If I can
exclude the root fh from this restriction (allow auth_unix to root fh
only) would it then be rfc ok?


--ben



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: NFSv2/3 requiring RPC_AUTH_GSS

[J. Bruce Fields]

On Sat, Mar 05, 2005 at 04:47:52AM -0500, Benjamin Bennett wrote:
> The problem I saw (can't require gss for v3 access) seems to be the
> result of two things:
> 
>   A) mountd needs to see the v3 host in exports (or it will return
> unknown host). So even though we just want to use gss, we need another
> export (auth_unix) to satisfy this.

Oh, right.

>   I wrote a little code to unconditionally send back a successful mount
> response with filehandle and included gss flavors. This led to the
> second problem:
> 
>   B) knfsd also validates host, so we again need the same auth_unix
> export as in A.

I'm not sure what you mean by "knfsd also validates host".  I think the
client mount program sends a NULL rpc call to nfsd, is that what you're
talking about?

>   The most simple work-around I could think of was making the auth_unix
> export ro, all_squash. But that still allows auth_unix anyone to mount
> and be nobody ;-)
> 
>   Whether a client is going to use gss for nfs transactions isn't
> necessarily known at mount time, so we can't just have mountd ignore
> hostnames when gss is going to be used.

Well, I suppose we could require mount to contact mountd using gss.
That seems much more sensible to me than what rfc2623 recommends.  Maybe
I'm missing some obvious problem.

--b.


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs