Re: [Nfs-ganesha-devel] Kerberos: Not working because response uses cached krb service from authgss_hash
Hi Matt,
Following is the link for pull request.
Pull request.
<https://github.com/nfs-ganesha/ntirpc/pull/31/commits/334e4c1c03109f0b5b43e154f5b389329831a2d8>
Will add a separate pull request for ganesha changes as well.
Thanks,
Sriram
On Mon, Dec 19, 2016 at 8:46 PM, Matt Benjamin wrote:
> Hi Sriram,
>
> Please send your change as a pull request against https://github.com/nfs-
> ganesha/ntirpc. We need to take some care to ensure that we properly
> enforce service and QOP guarantees. My understanding would have been that
> any request "still being processed" has been validated and unwrapped. If
> that's the case, then I do suspect that any further use of the request
> version of the service value is valid.
>
> Matt
>
> - Original Message -
> > From: "sriram patil"
> > To: nfs-ganesha-devel@lists.sourceforge.net
> > Sent: Monday, December 19, 2016 2:23:36 AM
> > Subject: [Nfs-ganesha-devel] Kerberos: Not working because response
> uses cached krb service from authgss_hash
> >
> >
> >
> > Hi,
> >
> > When handling kerberos requests ganesha fetches the cached
> svc_rpc_gss_data
> > from authgss_hash. If the kerberos service (authentication, integrity or
> > privacy) do not match with the one parsed from the request, ganesha
> changes
> > the service value in the cache. And continues to use the cached object
> for
> > all the further verification and when sending response to the client.
> Note
> > that there is no local copy of the gss data in the request, it uses the
> > cached object.
> >
> >
> >
> >
> > Code snippet which does the above mentioned lookup:
> >
> >
> > file: src/libntirpc/src/svc_auth_gss.c function: _svcauth_gss
> >
> > ` /* Context lookup. */
> >
> > if ((gc->gc_proc == RPCSEC_GSS_DATA)
> >
> > || (gc->gc_proc == RPCSEC_GSS_DESTROY)) {
> >
> > /* XXX fix prototype, toss junk args */
> >
> > gd = authgss_ctx_hash_get(gc);
> >
> > if (!gd)
> >
> > svcauth_gss_return(AUTH_REJECTEDCRED);
> >
> > gd_hashed = true;
> >
> > if (gc->gc_svc != gd->sec.svc)
> >
> > gd->sec.svc = gc->gc_svc;
> >
> > }`
> >
> >
> >
> >
> > Now let’s assume that the cached gss service is set to privacy (3).
> Before
> > the ongoing request can proceed, a new request comes in with OP_RENEW and
> > gss service set to integrity (2). As specified in the above snippet, this
> > will change the gss service value in the cache to integrity. This will
> > affect all the requests which are still being processed and may respond
> to
> > client with an incorrect gss service. Because of this the nfs client is
> > unable to interpret the response and fails with EIO. I am using linux nfs
> > client so it fails in method gss_unwrap_resp.
> >
> > I am continuously hitting this issue in case of server restarts when
> mounted
> > on the client with kerberos privacy. Is there any reason why we use the
> gss
> > service from the cache, though we have a local copy parsed from the
> actual
> > request stored in (rq_clntcred).
> >
> >
> > I have tried a fix to always use the gss service from the request
> > (rq_clntcred). This is working as expected and no errors on the client
> side.
> >
> >
> >
> >
> >
> > Thanks,
> >
> >
> >
> > Sriram
> >
> >
> --
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> > ___
> > Nfs-ganesha-devel mailing list
> > Nfs-ganesha-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
> >
>
> --
> Matt Benjamin
> Red Hat, Inc.
> 315 West Huron Street, Suite 140A
> Ann Arbor, Michigan 48103
>
> http://www.redhat.com/en/technologies/storage
>
> tel. 734-821-5101
> fax. 734-769-8938
> cel. 734-216-5309
>
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/intel___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
Re: [Nfs-ganesha-devel] Kerberos: Not working because response uses cached krb service from authgss_hash
Hi Sriram,
Please send your change as a pull request against
https://github.com/nfs-ganesha/ntirpc. We need to take some care to ensure
that we properly enforce service and QOP guarantees. My understanding would
have been that any request "still being processed" has been validated and
unwrapped. If that's the case, then I do suspect that any further use of the
request version of the service value is valid.
Matt
- Original Message -
> From: "sriram patil"
> To: nfs-ganesha-devel@lists.sourceforge.net
> Sent: Monday, December 19, 2016 2:23:36 AM
> Subject: [Nfs-ganesha-devel] Kerberos: Not working because response uses
> cached krb service from authgss_hash
>
>
>
> Hi,
>
> When handling kerberos requests ganesha fetches the cached svc_rpc_gss_data
> from authgss_hash. If the kerberos service (authentication, integrity or
> privacy) do not match with the one parsed from the request, ganesha changes
> the service value in the cache. And continues to use the cached object for
> all the further verification and when sending response to the client. Note
> that there is no local copy of the gss data in the request, it uses the
> cached object.
>
>
>
>
> Code snippet which does the above mentioned lookup:
>
>
> file: src/libntirpc/src/svc_auth_gss.c function: _svcauth_gss
>
> ` /* Context lookup. */
>
> if ((gc->gc_proc == RPCSEC_GSS_DATA)
>
> || (gc->gc_proc == RPCSEC_GSS_DESTROY)) {
>
> /* XXX fix prototype, toss junk args */
>
> gd = authgss_ctx_hash_get(gc);
>
> if (!gd)
>
> svcauth_gss_return(AUTH_REJECTEDCRED);
>
> gd_hashed = true;
>
> if (gc->gc_svc != gd->sec.svc)
>
> gd->sec.svc = gc->gc_svc;
>
> }`
>
>
>
>
> Now let’s assume that the cached gss service is set to privacy (3). Before
> the ongoing request can proceed, a new request comes in with OP_RENEW and
> gss service set to integrity (2). As specified in the above snippet, this
> will change the gss service value in the cache to integrity. This will
> affect all the requests which are still being processed and may respond to
> client with an incorrect gss service. Because of this the nfs client is
> unable to interpret the response and fails with EIO. I am using linux nfs
> client so it fails in method gss_unwrap_resp.
>
> I am continuously hitting this issue in case of server restarts when mounted
> on the client with kerberos privacy. Is there any reason why we use the gss
> service from the cache, though we have a local copy parsed from the actual
> request stored in (rq_clntcred).
>
>
> I have tried a fix to always use the gss service from the request
> (rq_clntcred). This is working as expected and no errors on the client side.
>
>
>
>
>
> Thanks,
>
>
>
> Sriram
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> ___
> Nfs-ganesha-devel mailing list
> Nfs-ganesha-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
>
--
Matt Benjamin
Red Hat, Inc.
315 West Huron Street, Suite 140A
Ann Arbor, Michigan 48103
http://www.redhat.com/en/technologies/storage
tel. 734-821-5101
fax. 734-769-8938
cel. 734-216-5309
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
[Nfs-ganesha-devel] Kerberos: Not working because response uses cached krb service from authgss_hash
Hi,
When handling kerberos requests ganesha fetches the cached svc_rpc_gss_data
from authgss_hash. If the kerberos service (authentication, integrity or
privacy) do not match with the one parsed from the request, ganesha changes
the service value in the cache. And continues to use the cached object for
all the further verification and when sending response to the client. Note
that there is no local copy of the gss data in the request, it uses the
cached object.
Code snippet which does the above mentioned lookup:
file: src/libntirpc/src/svc_auth_gss.c function: _svcauth_gss
`/* Context lookup. */
if ((gc->gc_proc == RPCSEC_GSS_DATA)
|| (gc->gc_proc == RPCSEC_GSS_DESTROY)) {
/* XXX fix prototype, toss junk args */
gd = authgss_ctx_hash_get(gc);
if (!gd)
svcauth_gss_return(AUTH_REJECTEDCRED);
gd_hashed = true;
if (gc->gc_svc != gd->sec.svc)
gd->sec.svc = gc->gc_svc;
}`
Now let’s assume that the cached gss service is set to privacy (3). Before
the ongoing request can proceed, a new request comes in with OP_RENEW and
gss service set to integrity (2). As specified in the above snippet, this
will change the gss service value in the cache to integrity. This will
affect all the requests which are still being processed and may respond to
client with an incorrect gss service. Because of this the nfs client is
unable to interpret the response and fails with EIO. I am using linux nfs
client so it fails in method gss_unwrap_resp.
I am continuously hitting this issue in case of server restarts when
mounted on the client with kerberos privacy. Is there any reason why we use
the gss service from the cache, though we have a local copy parsed from the
actual request stored in (rq_clntcred).
I have tried a fix to always use the gss service from the request
(rq_clntcred). This is working as expected and no errors on the client side.
Thanks,
Sriram
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
