From patchwork Fri Apr 3 03:03:50 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tom Hebb X-Patchwork-Id: 6153351 Return-Path: X-Original-To: patchwork-linux-fsdevel@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 19B0F9F1BE for ; Fri, 3 Apr 2015 03:03:58 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 0CC1C203B1 for ; Fri, 3 Apr 2015 03:03:57 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id CF0E4203AA for ; Fri, 3 Apr 2015 03:03:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753076AbbDCDDx (ORCPT ); Thu, 2 Apr 2015 23:03:53 -0400 Received: from mail-qc0-f173.google.com ([209.85.216.173]:33508 "EHLO mail-qc0-f173.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751083AbbDCDDw (ORCPT ); Thu, 2 Apr 2015 23:03:52 -0400 Received: by qcrf4 with SMTP id f4so69657490qcr.0; Thu, 02 Apr 2015 20:03:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :content-type:content-transfer-encoding; bh=rn5Ondaw3gmgRfn5uhIbGwLRB70TYjdnKyENEC3UVpM=; b=Mr43Mb76O6lcjN9lGkSoEGElHjv0RF7+boXXAWrp7D8Yp1V4HbU9Cum17PoSDN2ojD oBkJYjrcG2W+XLGA62vMyaY6cXivkeGy0gMMNYVh1vQuPMCKeIFiqBKfN5Oct/dSQQcd g36ys/ccNBlN42r5RN7IapWUiAaNOUd5zEN/O1I1HE+40X28TXyNVLxtHm7p4Dtjzu9y gdMD3DPsI0v1Ms4Mw6yKnCVhkI0P0GILlHtlRca1C04NBnuVqiKJR3CWL/9rrYkZaWHA U6+nG4XCgnK7geo6APjayuHFqtdoNjrD6r9MS0OuLFX+Bycy4PNRxlkSywEKoaFoMgzV g4Rg== X-Received: by 10.55.26.222 with SMTP id l91mr714545qkh.32.1428030231650; Thu, 02 Apr 2015 20:03:51 -0700 (PDT) Received: from [130.64.128.230] (resnet-130-64-128-230.medford.tufts.edu. [130.64.128.230]) by mx.google.com with ESMTPSA id u95sm4852144qge.35.2015.04.02.20.03.50 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Apr 2015 20:03:51 -0700 (PDT) Message-ID: <551E0316.3040100@gmail.com> Date: Thu, 02 Apr 2015 23:03:50 -0400 From: Thomas Hebb User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: linux-fsdevel@vger.kernel.org CC: stable@vger.kernel.org, Andrew Morton , Hin-Tak Leung , Sergei Antonov , Anton Altaparmakov , Fabian Frederick , Christian Kujau Subject: [PATCH] hfsplus: don't store special "osx" xattr prefix on-disk Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org X-Spam-Status: No, score=-6.8 required=5.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED, FREEMAIL_FROM, RCVD_IN_DNSWL_HI, T_DKIM_INVALID, T_RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On Mac OS X, HFS+ extended attributes are not namespaced. Since we want to be compatible with OS X filesystems and yet still support the Linux namespacing system, the hfsplus driver implements a special "osx" namespace that is reported for any attribute that is not namespaced on-disk. However, the current code for getting and setting these unprefixed attributes is broken. hfsplus_osx_setattr() and hfsplus_osx_getattr() are passed names that have already had their "osx." prefixes stripped by the generic functions. The functions first, quite correctly, check those names to make sure that they aren't prefixed with a known namespace, which would allow namespace access restrictions to be bypassed. However, the functions then prepend "osx." to the name they're given before passing it on to hfsplus_getattr() and hfsplus_setattr(). Not only does this cause the "osx." prefix to be stored on-disk, defeating its purpose, it also breaks the check for the special "com.apple.FinderInfo" attribute, which is reported for all files, and--as a consequence--makes some userspace applications (e.g. GNU patch) fail even when extended attributes are not otherwise in use. There are three commits which have touched this particular code: 127e5f5ae51e ("hfsplus: rework functionality of getting, setting and deleting of extended attributes") b168fff72109 ("hfsplus: use xattr handlers for removexattr") bf29e886b242 ("hfsplus: correct usage of HFSPLUS_ATTR_MAX_STRLEN for non-English attributes") The first commit creates the functions to begin with. The namespace is prepended by the original code, which I believe was correct at the time, since hfsplus_?etattr() stripped the prefix if found. The second commit removed this behavior from hfsplus_?etattr() and appears to have been intended to also remove the prefixing from hfsplus_osx_?etattr(). However, what it actually did was remove a necessary strncpy() call, breaking the osx namespace entirely. The third and final commit re-added the strncpy() call as it was originally (but didn't mention it in its commit message). This commit removes the strncpy() call, as b168fff did, but also fixes the calls to hfsplus_?etattr() to directly pass in the name received from userspace rather than an empty buffer, which is what b168fff did. Fixes: b168fff72109 ("hfsplus: use xattr handlers for removexattr") Cc: stable@vger.kernel.org Cc: Andrew Morton Cc: Hin-Tak Leung Cc: Sergei Antonov Cc: Anton Altaparmakov Cc: Fabian Frederick Cc: Christian Kujau Signed-off-by: Thomas Hebb Reviewed-by: Vyacheslav Dubeyko --- fs/hfsplus/xattr.c | 38 ++++++++++++++------------------------ 1 file changed, 14 insertions(+), 24 deletions(-) diff --git a/fs/hfsplus/xattr.c b/fs/hfsplus/xattr.c index d98094a..ff10f3d 100644 --- a/fs/hfsplus/xattr.c +++ b/fs/hfsplus/xattr.c @@ -806,9 +806,6 @@ end_removexattr: static int hfsplus_osx_getxattr(struct dentry *dentry, const char *name, void *buffer, size_t size, int type) { - char *xattr_name; - int res; - if (!strcmp(name, "")) return -EINVAL; @@ -818,24 +815,19 @@ static int hfsplus_osx_getxattr(struct dentry *dentry, const char *name, */ if (is_known_namespace(name)) return -EOPNOTSUPP; - xattr_name = kmalloc(NLS_MAX_CHARSET_SIZE * HFSPLUS_ATTR_MAX_STRLEN - + XATTR_MAC_OSX_PREFIX_LEN + 1, GFP_KERNEL); - if (!xattr_name) - return -ENOMEM; - strcpy(xattr_name, XATTR_MAC_OSX_PREFIX); - strcpy(xattr_name + XATTR_MAC_OSX_PREFIX_LEN, name); - res = hfsplus_getxattr(dentry, xattr_name, buffer, size); - kfree(xattr_name); - return res; + /* + * osx is the namespace we use to indicate an unprefixed + * attribute on the filesystem (like the ones that OS X + * creates), so we pass the name through unmodified (after + * ensuring it doesn't conflict with another namespace). + */ + return hfsplus_getxattr(dentry, name, buffer, size); } static int hfsplus_osx_setxattr(struct dentry *dentry, const char *name, const void *buffer, size_t size, int flags, int type) { - char *xattr_name; - int res; - if (!strcmp(name, "")) return -EINVAL; @@ -845,16 +837,14 @@ static int hfsplus_osx_setxattr(struct dentry *dentry, const char *name, */ if (is_known_namespace(name)) return -EOPNOTSUPP; - xattr_name = kmalloc(NLS_MAX_CHARSET_SIZE * HFSPLUS_ATTR_MAX_STRLEN - + XATTR_MAC_OSX_PREFIX_LEN + 1, GFP_KERNEL); - if (!xattr_name) - return -ENOMEM; - strcpy(xattr_name, XATTR_MAC_OSX_PREFIX); - strcpy(xattr_name + XATTR_MAC_OSX_PREFIX_LEN, name); - res = hfsplus_setxattr(dentry, xattr_name, buffer, size, flags); - kfree(xattr_name); - return res; + /* + * osx is the namespace we use to indicate an unprefixed + * attribute on the filesystem (like the ones that OS X + * creates), so we pass the name through unmodified (after + * ensuring it doesn't conflict with another namespace). + */ + return hfsplus_setxattr(dentry, name, buffer, size, flags); } static size_t hfsplus_osx_listxattr(struct dentry *dentry, char *list,