From: Andy Adamson <[email protected]>
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 <[email protected]>
---
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)
Hi Andy
On Fri, Dec 12, 2014 at 5:33 PM, <[email protected]> wrote:
> From: Andy Adamson <[email protected]>
>
> 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
[email protected]
On Fri, Dec 12, 2014 at 07:26:39PM -0500, Trond Myklebust wrote:
> Hi Andy
>
> On Fri, Dec 12, 2014 at 5:33 PM, <[email protected]> wrote:
> > From: Andy Adamson <[email protected]>
> >
> > 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.