* [PATCH 1/1] SUNRPC add rpc_gss_svc_t to gssd upcall
@ 2014-12-12 22:33 andros
2014-12-13 0:26 ` Trond Myklebust
0 siblings, 1 reply; 3+ messages in thread
From: andros @ 2014-12-12 22:33 UTC (permalink / raw)
To: trond.myklebust; +Cc: linux-nfs, Andy Adamson
From: Andy Adamson <andros@netapp.com>
Otherwise rpc.gssd will send a V4 NULL RPCSEC_GSS_INIT call with an RPCSEC_GSS
service of rpc_gss_svc_none for rpc_sec_gss_svc_integrity/privacy requests
from the kernel.
This change does not break current versions of rpc.gssd, and there is a
companion rpc.gssd patch: GSSD add rpc_gss_svc_t to the gssd upcall
Signed-off-by: Andy Adamson <andros@netapp.com>
---
net/sunrpc/auth_gss/auth_gss.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/net/sunrpc/auth_gss/auth_gss.c b/net/sunrpc/auth_gss/auth_gss.c
index 53ed8d3..48054dc 100644
--- a/net/sunrpc/auth_gss/auth_gss.c
+++ b/net/sunrpc/auth_gss/auth_gss.c
@@ -449,8 +449,9 @@ static int gss_encode_v1_msg(struct gss_upcall_msg *gss_msg,
size_t buflen = sizeof(gss_msg->databuf);
int len;
- len = scnprintf(p, buflen, "mech=%s uid=%d ", mech->gm_name,
- from_kuid(&init_user_ns, gss_msg->uid));
+ len = scnprintf(p, buflen, "mech=%s uid=%d svc=%d ", mech->gm_name,
+ from_kuid(&init_user_ns, gss_msg->uid),
+ gss_msg->auth->service);
buflen -= len;
p += len;
gss_msg->msg.len = len;
--
1.9.3 (Apple Git-50)
^ permalink raw reply related [flat|nested] 3+ messages in thread
* Re: [PATCH 1/1] SUNRPC add rpc_gss_svc_t to gssd upcall
2014-12-12 22:33 [PATCH 1/1] SUNRPC add rpc_gss_svc_t to gssd upcall andros
@ 2014-12-13 0:26 ` Trond Myklebust
2014-12-13 3:45 ` J. Bruce Fields
0 siblings, 1 reply; 3+ messages in thread
From: Trond Myklebust @ 2014-12-13 0:26 UTC (permalink / raw)
To: William Andros Adamson; +Cc: Linux NFS Mailing List
Hi Andy
On Fri, Dec 12, 2014 at 5:33 PM, <andros@netapp.com> wrote:
> From: Andy Adamson <andros@netapp.com>
>
> Otherwise rpc.gssd will send a V4 NULL RPCSEC_GSS_INIT call with an RPCSEC_GSS
> service of rpc_gss_svc_none for rpc_sec_gss_svc_integrity/privacy requests
> from the kernel.
I thought this behaviour of using rpc_gss_svc_none for the RPCSEC_GSS
negotiation in userland and then "stepping up" to a stricter service
in the kernel had been declared legal by the powers that be. What is
the concern about doing so?
Cheers,
Trond
--
Trond Myklebust
Linux NFS client maintainer, PrimaryData
trond.myklebust@primarydata.com
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH 1/1] SUNRPC add rpc_gss_svc_t to gssd upcall
2014-12-13 0:26 ` Trond Myklebust
@ 2014-12-13 3:45 ` J. Bruce Fields
0 siblings, 0 replies; 3+ messages in thread
From: J. Bruce Fields @ 2014-12-13 3:45 UTC (permalink / raw)
To: Trond Myklebust; +Cc: William Andros Adamson, Linux NFS Mailing List
On Fri, Dec 12, 2014 at 07:26:39PM -0500, Trond Myklebust wrote:
> Hi Andy
>
> On Fri, Dec 12, 2014 at 5:33 PM, <andros@netapp.com> wrote:
> > From: Andy Adamson <andros@netapp.com>
> >
> > Otherwise rpc.gssd will send a V4 NULL RPCSEC_GSS_INIT call with an RPCSEC_GSS
> > service of rpc_gss_svc_none for rpc_sec_gss_svc_integrity/privacy requests
> > from the kernel.
>
> I thought this behaviour of using rpc_gss_svc_none for the RPCSEC_GSS
> negotiation in userland and then "stepping up" to a stricter service
> in the kernel had been declared legal by the powers that be.
Yes, in fact:
https://www.ietf.org/rfc/rfc2203.txt 5.2.2:
In a creation request, the seq_num and service fields are
undefined and both must be ignored by the server.
--b.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2014-12-13 3:45 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-12-12 22:33 [PATCH 1/1] SUNRPC add rpc_gss_svc_t to gssd upcall andros
2014-12-13 0:26 ` Trond Myklebust
2014-12-13 3:45 ` J. Bruce Fields
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox