From patchwork Tue Mar 19 16:56:32 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Dave Chiluk X-Patchwork-Id: 2302901 Return-Path: X-Original-To: patchwork-linux-nfs@patchwork.kernel.org Delivered-To: patchwork-process-083081@patchwork1.kernel.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by patchwork1.kernel.org (Postfix) with ESMTP id 10CD63FD8C for ; Tue, 19 Mar 2013 16:56:54 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756996Ab3CSQ4w (ORCPT ); Tue, 19 Mar 2013 12:56:52 -0400 Received: from youngberry.canonical.com ([91.189.89.112]:48507 "EHLO youngberry.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756396Ab3CSQ4w (ORCPT ); Tue, 19 Mar 2013 12:56:52 -0400 Received: from cpe-70-124-70-187.austin.res.rr.com ([70.124.70.187] helo=[192.168.1.101]) by youngberry.canonical.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1UHzqD-0001R7-6p; Tue, 19 Mar 2013 16:56:49 +0000 Message-ID: <514898C0.8050101@canonical.com> Date: Tue, 19 Mar 2013 11:56:32 -0500 From: Dave Chiluk User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3 MIME-Version: 1.0 To: "Myklebust, Trond" CC: "linux-nfs@vger.kernel.org" Subject: Re: NFSv4 setattr null-terminates strings References: <513A1BD1.6060709@canonical.com> <4FA345DA4F4AE44899BD2B03EEEC2FA9286B6F80@sacexcmbx05-prd.hq.netapp.com> In-Reply-To: <4FA345DA4F4AE44899BD2B03EEEC2FA9286B6F80@sacexcmbx05-prd.hq.netapp.com> X-Enigmail-Version: 1.5.1 Sender: linux-nfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org On 03/08/2013 12:33 PM, Myklebust, Trond wrote: > On Fri, 2013-03-08 at 11:11 -0600, Dave Chiluk wrote: >> As of commit 57e62324e469e092ecc6c94a7a86fe4bd6ac5172, the SETATTR nfsv4 >> command now null terminates fattr_owner and fattr_owner_group. >> >> Here is an example excerpt from a tcpdump >> Opcode: SETATTR (34) >> stateid >> [StateID Hash: 0xafa9] >> seqid: 0x00000000 >> Data: 000000000000000000000000 >> obj_attributes >> attrmask >> recc_attr: FATTR4_OWNER_GROUP (37) >> fattr4_owner_group: groupname@domainname.com >> length: 25 >> >> This means that even though there are actually 24 characters in >> groupname@domainname.com, we now send 24 characters + 1 null character. >> Hence the total length of 25. Previously the client would send just the >> 24 characters and set length to 24. >> >> This isn't an issue for communication with other Linux machines, but it >> is an issue for interaction with AIX machines. As is discussed here. >> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1101292 >> >> I attempted to read the RFC available here >> http://tools.ietf.org/html/rfc5661, but have not been able to find a >> statement instructing one way or the other. >> >> So the question becomes, is it correct for linux to be sending this null >> terminator when read against the RFC, or is it AIX's responsibility to >> handle null-terminated strings? > > The client is definitely in error here according to RFC3530. Please > check if the attached patch fixes the issue for you. > > Cheers > Trond > Thanks again for the patch. When will this get pushed upstream? I'm blocked by the upstream commit, since I don't want to pull this in as a SAUCE patch. Dave. From 90eabc5dfde58de5c37de3866f427da02e86ce17 Mon Sep 17 00:00:00 2001 From: Trond Myklebust Date: Fri, 8 Mar 2013 12:56:37 -0500 Subject: [PATCH] NFSv4: Fix the string length returned by the idmapper Functions like nfs_map_uid_to_name() and nfs_map_gid_to_group() are expected to return a string without any terminating NUL character. Regression introduced by commit 57e62324e469e092ecc6c94a7a86fe4bd6ac5172 (NFS: Store the legacy idmapper result in the keyring). Reported-by: Dave Chiluk Signed-off-by: Trond Myklebust Cc: Bryan Schumaker Cc: stable@vger.kernel.org [>=3.4] --- fs/nfs/idmap.c | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/fs/nfs/idmap.c b/fs/nfs/idmap.c index dc0f98d..c516da5 100644 --- a/fs/nfs/idmap.c +++ b/fs/nfs/idmap.c @@ -726,9 +726,9 @@ out1: return ret; } -static int nfs_idmap_instantiate(struct key *key, struct key *authkey, char *data) +static int nfs_idmap_instantiate(struct key *key, struct key *authkey, char *data, size_t datalen) { - return key_instantiate_and_link(key, data, strlen(data) + 1, + return key_instantiate_and_link(key, data, datalen, id_resolver_cache->thread_keyring, authkey); } @@ -738,6 +738,7 @@ static int nfs_idmap_read_and_verify_message(struct idmap_msg *im, struct key *key, struct key *authkey) { char id_str[NFS_UINT_MAXLEN]; + size_t len; int ret = -ENOKEY; /* ret = -ENOKEY */ @@ -747,13 +748,15 @@ static int nfs_idmap_read_and_verify_message(struct idmap_msg *im, case IDMAP_CONV_NAMETOID: if (strcmp(upcall->im_name, im->im_name) != 0) break; - sprintf(id_str, "%d", im->im_id); - ret = nfs_idmap_instantiate(key, authkey, id_str); + /* Note: here we store the NUL terminator too */ + len = sprintf(id_str, "%d", im->im_id) + 1; + ret = nfs_idmap_instantiate(key, authkey, id_str, len); break; case IDMAP_CONV_IDTONAME: if (upcall->im_id != im->im_id) break; - ret = nfs_idmap_instantiate(key, authkey, im->im_name); + len = strlen(im->im_name); + ret = nfs_idmap_instantiate(key, authkey, im->im_name, len); break; default: ret = -EINVAL; -- 1.8.1.4