1. 14 Nov, 2015 1 commit
  2. 17 Apr, 2015 4 commits
    • Thomas Hebb's avatar
      hfsplus: don't store special "osx" xattr prefix on-disk · db579e76
      Thomas Hebb authored
      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 five commits which have touched this particular code:
      
        127e5f5a ("hfsplus: rework functionality of getting, setting and deleting of extended attributes")
        b168fff7 ("hfsplus: use xattr handlers for removexattr")
        bf29e886 ("hfsplus: correct usage of HFSPLUS_ATTR_MAX_STRLEN for non-English attributes")
        fcacbd95e121 ("fs/hfsplus: move xattr_name allocation in hfsplus_getxattr()")
        ec1bbd346f18 ("fs/hfsplus: move xattr_name allocation in hfsplus_setxattr()")
      
      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
      removes this behavior from hfsplus_?etattr() and appears to have been
      intended to also remove the prefixing from hfsplus_osx_?etattr().
      However, what it actually does is remove a necessary strncpy() call
      completely, breaking the osx namespace entirely.  The third commit re-adds
      the strncpy() call as it was originally, but doesn't mention it in its
      commit message.  The final two commits refactor the code and don't affect
      its functionality.
      
      This commit does what b168fff7 attempted to do (prevent the prefix from
      being added), but does it properly, instead of passing in an empty buffer
      (which is what b168fff7 actually did).
      
      Fixes: b168fff7
      
       ("hfsplus: use xattr handlers for removexattr")
      Signed-off-by: default avatarThomas Hebb <tommyhebb@gmail.com>
      Cc: Hin-Tak Leung <htl10@users.sourceforge.net>
      Cc: Sergei Antonov <saproj@gmail.com>
      Cc: Anton Altaparmakov <anton@tuxera.com>
      Cc: Fabian Frederick <fabf@skynet.be>
      Cc: Christian Kujau <lists@nerdbynature.de>
      Cc: Christoph Hellwig <hch@infradead.org>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Viacheslav Dubeyko <slava@dubeyko.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      db579e76
    • Fabian Frederick's avatar
      fs/hfsplus: use bool instead of int for is_known_namespace() return value · 1ad8d63d
      Fabian Frederick authored
      
      
      is_known_namespace() only returns true/false.  Also remove inline and let
      compiler decide what to do with static functions.
      Signed-off-by: default avatarFabian Frederick <fabf@skynet.be>
      Cc: "David S. Miller" <davem@davemloft.net>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      1ad8d63d
    • Fabian Frederick's avatar
      fs/hfsplus: move xattr_name allocation in hfsplus_setxattr() · 5e61473e
      Fabian Frederick authored
      
      
      security/trusted/user/osx setxattr did the same
      xattr_name initialization. Move that operation in hfsplus_setxattr().
      
      Tested with security/trusted/user getfattr/setfattr
      Signed-off-by: default avatarFabian Frederick <fabf@skynet.be>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      5e61473e
    • Fabian Frederick's avatar
      fs/hfsplus: move xattr_name allocation in hfsplus_getxattr() · a3cef4cd
      Fabian Frederick authored
      
      
      security/trusted/user/osx getxattr did the same
      xattr_name initialization. Move that operation in hfsplus_getxattr().
      
      Tested with security/trusted/user getfattr/setfattr
      Signed-off-by: default avatarFabian Frederick <fabf@skynet.be>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      a3cef4cd
  3. 15 Apr, 2015 1 commit
  4. 06 Jun, 2014 5 commits
    • Christian Kujau's avatar
      hfsplus: fix compiler warning on PowerPC · df3d4e7a
      Christian Kujau authored
      Commit a99b7069
      
       ("hfsplus: Fix undefined __divdi3 in
      hfsplus_init_header_node()") introduced do_div() to xattr.c and the
      warning below too.
      
      As Geert remarked: "tmp" is "loff_t" which is "__kernel_loff_t", which
      is "long long", i.e.  signed, while include/asm-generic/div64.h compares
      its type with "uint64_t".  As inode sizes are positive, it should be
      safe to change the type of "tmp" to "u64".
      
        In file included from
        arch/powerpc/include/asm/div64.h:1:0,
                          from include/linux/kernel.h:124,
                          from include/asm-generic/bug.h:13,
                          from arch/powerpc/include/asm/bug.h:127,
                          from include/linux/bug.h:4,
                          from include/linux/thread_info.h:11,
                          from include/asm-generic/preempt.h:4,
                          from arch/powerpc/include/generated/asm/preempt.h:1,
                          from include/linux/preempt.h:18,
                          from include/linux/spinlock.h:50,
                          from include/linux/wait.h:8,
                          from include/linux/fs.h:6,
                          from fs/hfsplus/hfsplus_fs.h:19,
                          from fs/hfsplus/xattr.c:9:
        fs/hfsplus/xattr.c: In function 'hfsplus_init_header_node':
        include/asm-generic/div64.h:43:28: warning: comparison of distinct pointer types lacks a cast [enabled by default]
           (void)(((typeof((n)) *)0) == ((uint64_t *)0)); \
                                     ^
        fs/hfsplus/xattr.c:86:2: note: in expansion of macro 'do_div'
           do_div(tmp, node_size);
           ^
      Signed-off-by: default avatarChristian Kujau <lists@nerdbynature.de>
      Signed-off-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
      Acked-by: default avatarSergei Antonov <saproj@gmail.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      df3d4e7a
    • Fabian Frederick's avatar
    • Sergei Antonov's avatar
      hfsplus: fix "unused node is not erased" error · 2cd282a1
      Sergei Antonov authored
      Zero newly allocated extents in the catalog tree if volume attributes
      tell us to.  Not doing so we risk getting the "unused node is not
      erased" error.  See kHFSUnusedNodeFix flag in Apple's source code for
      reference.
      
      There was a previous commit clearing the node when it is freed: commit
      899bed05
      
       ("hfsplus: fix issue with unzeroed unused b-tree nodes").
      But it did not handle newly allocated extents (this patch fixes it).
      And it zeroed nodes in all trees unconditionally which is an overkill.
      
      This patch adds a condition and also switches to 'tree->node_size' as a
      simpler method of getting the length to zero.
      Signed-off-by: default avatarSergei Antonov <saproj@gmail.com>
      Cc: Anton Altaparmakov <aia21@cam.ac.uk>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Christoph Hellwig <hch@infradead.org>
      Cc: Vyacheslav Dubeyko <slava@dubeyko.com>
      Cc: Hin-Tak Leung <htl10@users.sourceforge.net>
      Cc: Kyle Laracey <kalaracey@gmail.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      2cd282a1
    • Hin-Tak Leung's avatar
      hfsplus: correct usage of HFSPLUS_ATTR_MAX_STRLEN for non-English attributes · bf29e886
      Hin-Tak Leung authored
      
      
      HFSPLUS_ATTR_MAX_STRLEN (=127) is the limit of attribute names for the
      number of unicode character (UTF-16BE) storable in the HFS+ file system.
      Almost all the current usage of it is wrong, in relation to NLS to
      on-disk conversion.
      
      Except for one use calling hfsplus_asc2uni (which should stay the same)
      and its uses in calling hfsplus_uni2asc (which was corrected in the
      earlier patch in this series concerning usage of hfsplus_uni2asc), all
      the other uses are of the forms:
      
      - char buffer[size]
      
      - bound check: "if (namespace_adjusted_input_length > size) return failure;"
      
      Conversion between on-disk unicode representation and NLS char strings
      (in whichever direction) always needs to accommodate the worst-case NLS
      conversion, so all char buffers of that size need to have a
      NLS_MAX_CHARSET_SIZE x .
      
      The bound checks are all wrong, since they compare nls_length derived
      from strlen() to a unicode length limit.
      
      It turns out that all the bound-checks do is to protect
      hfsplus_asc2uni(), which can fail if the input is too large.
      
      There is only one usage of it as far as attributes are concerned, in
      hfsplus_attr_build_key().  It is in turn used by hfsplus_find_attr(),
      hfsplus_create_attr(), hfsplus_delete_attr().  Thus making sure that
      errors from hfsplus_asc2uni() is caught in hfsplus_attr_build_key() and
      propagated is sufficient to replace all the bound checks.
      
      Unpropagated errors from hfsplus_asc2uni() in the file catalog code was
      addressed recently in an independent patch "hfsplus: fix longname
      handling" by Sougata Santra.
      
      Before this patch, trying to set a 55 CJK character (in a UTF-8 locale,
      > 127/3=42) attribute plus user prefix fails with:
      
          $ setfattr -n user.`cat testing-string` -v `cat testing-string` \
              testing-string
          setfattr: testing-string: Operation not supported
      
      and retrieving a stored long attributes is particular ugly(!):
      
          find /mnt/* -type f -exec getfattr -d {} \;
          getfattr: /mnt/testing-string: Input/output error
      
      with console log:
          [268008.389781] hfsplus: unicode conversion failed
      
      After the patch, both of the above works.
      
      FYI, the test attribute string is prepared with:
      
      echo -e -n \
      "\xe9\x80\x99\xe6\x98\xaf\xe4\xb8\x80\xe5\x80\x8b\xe9\x9d\x9e\xe5" \
      "\xb8\xb8\xe6\xbc\xab\xe9\x95\xb7\xe8\x80\x8c\xe6\xa5\xb5\xe5\x85" \
      "\xb6\xe4\xb9\x8f\xe5\x91\xb3\xe5\x92\x8c\xe7\x9b\xb8\xe7\x95\xb6" \
      "\xe7\x84\xa1\xe8\xb6\xa3\xe3\x80\x81\xe4\xbb\xa5\xe5\x8f\x8a\xe7" \
      "\x84\xa1\xe7\x94\xa8\xe7\x9a\x84\xe3\x80\x81\xe5\x86\x8d\xe5\x8a" \
      "\xa0\xe4\xb8\x8a\xe6\xaf\xab\xe7\x84\xa1\xe6\x84\x8f\xe7\xbe\xa9" \
      "\xe7\x9a\x84\xe6\x93\xb4\xe5\xb1\x95\xe5\xb1\xac\xe6\x80\xa7\xef" \
      "\xbc\x8c\xe8\x80\x8c\xe5\x85\xb6\xe5\x94\xaf\xe4\xb8\x80\xe5\x89" \
      "\xb5\xe5\xbb\xba\xe7\x9b\xae\xe7\x9a\x84\xe5\x83\x85\xe6\x98\xaf" \
      "\xe7\x82\xba\xe4\xba\x86\xe6\xb8\xac\xe8\xa9\xa6\xe4\xbd\x9c\xe7" \
      "\x94\xa8\xe3\x80\x82" | tr -d ' '
      
      (= "pointlessly long attribute for testing", elaborate Chinese in
      UTF-8 enoding).
      
      However, it is not possible to set double the size (110 + 5 is still
      under 127) in a UTF-8 locale:
      
          $setfattr -n user.`cat testing-string testing-string` -v \
              `cat testing-string testing-string` testing-string
          setfattr: testing-string: Numerical result out of range
      
      110 CJK char in UTF-8 is 330 bytes - the generic get/set attribute
      system call code in linux/fs/xattr.c imposes a 255 byte limit.  One can
      use a combination of iconv to encode content, changing terminal locale
      for viewing, and an nls=cp932/cp936/cp949/cp950 mount option to fully
      use 127-unicode attribute in a double-byte locale.
      
      Also, as an additional information, it is possible to (mis-)use unicode
      half-width/full-width forms (U+FFxx) to write attributes which looks
      like english but not actually ascii.
      
      Thanks Anton Altaparmakov for reviewing the earlier ideas behind this
      change.
      
      [akpm@linux-foundation.org: fix build]
      [akpm@linux-foundation.org: fix build]
      Signed-off-by: default avatarHin-Tak Leung <htl10@users.sourceforge.net>
      Cc: Anton Altaparmakov <anton@tuxera.com>
      Cc: Vyacheslav Dubeyko <slava@dubeyko.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Christoph Hellwig <hch@infradead.org>
      Cc: Sougata Santra <sougata@tuxera.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      bf29e886
    • Hin-Tak Leung's avatar
      hfsplus: fix worst-case unicode to char conversion of file names and attributes · 017f8da4
      Hin-Tak Leung authored
      
      
      This is a series of 3 patches which corrects issues in HFS+ concerning
      the use of non-english file names and attributes.  Names and attributes
      are stored internally as UTF-16 units up to a fixed maximum size, and
      convert to and from user-representation by NLS.  The code incorrectly
      assume that NLS string lengths are equal to unicode lengths, which is
      only true for English ascii usage.
      
      This patch (of 3):
      
      The HFS Plus Volume Format specification (TN1150) states that file names
      are stored internally as a maximum of 255 unicode characters, as defined
      by The Unicode Standard, Version 2.0 [Unicode, Inc.  ISBN
      0-201-48345-9].  File names are converted by the NLS system on Linux
      before presented to the user.
      
      255 CJK characters converts to UTF-8 with 1 unicode character to up to 3
      bytes, and to GB18030 with 1 unicode character to up to 4 bytes.  Thus,
      trying in a UTF-8 locale to list files with names of more than 85 CJK
      characters results in:
      
          $ ls /mnt
          ls: reading directory /mnt: File name too long
      
      The receiving buffer to hfsplus_uni2asc() needs to be 255 x
      NLS_MAX_CHARSET_SIZE bytes, not 255 bytes as the code has always been.
      
      Similar consideration applies to attributes, which are stored internally
      as a maximum of 127 UTF-16BE units.  See XNU source for an up-to-date
      reference on attributes.
      
      Strictly speaking, the maximum value of NLS_MAX_CHARSET_SIZE = 6 is not
      attainable in the case of conversion to UTF-8, as going beyond 3 bytes
      requires the use of surrogate pairs, i.e.  consuming two input units.
      
      Thanks Anton Altaparmakov for reviewing an earlier version of this
      change.
      
      This patch fixes all callers of hfsplus_uni2asc(), and also enables the
      use of long non-English file names in HFS+.  The getting and setting,
      and general usage of long non-English attributes requires further
      forthcoming work, in the following patches of this series.
      
      [akpm@linux-foundation.org: fix build]
      Signed-off-by: default avatarHin-Tak Leung <htl10@users.sourceforge.net>
      Reviewed-by: default avatarAnton Altaparmakov <anton@tuxera.com>
      Cc: Vyacheslav Dubeyko <slava@dubeyko.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Christoph Hellwig <hch@infradead.org>
      Cc: Sougata Santra <sougata@tuxera.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      017f8da4
  5. 31 Jan, 2014 1 commit
  6. 26 Jan, 2014 2 commits
  7. 15 Nov, 2013 1 commit
    • Geert Uytterhoeven's avatar
      hfsplus: Fix undefined __divdi3 in hfsplus_init_header_node() · a99b7069
      Geert Uytterhoeven authored
      ERROR: "__divdi3" [fs/hfsplus/hfsplus.ko] undefined!
      
      Introduced by commit 099e9245
      
       ("hfsplus: implement attributes file's
      header node initialization code").
      
      i_size_read() returns loff_t, which is long long, i.e.  64-bit.  node_size
      is size_t, which is either 32-bit or 64-bit.  Hence
      "i_size_read(attr_file) / node_size" is a 64-by-32 or 64-by-64 division,
      causing (some versions of) gcc to emit a call to __divdi3().
      
      Fortunately node_size is actually 16-bit, as the sole caller of
      hfsplus_init_header_node() passes a u16.  Hence change its type from
      size_t to u16, and use do_div() to perform a 64-by-32 division.
      
      Not seen in m68k/allmodconfig in -next, so it really depends on the
      verion of gcc.
      Signed-off-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
      Cc: Vyacheslav Dubeyko <slava@dubeyko.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      a99b7069
  8. 13 Nov, 2013 2 commits
  9. 11 Sep, 2013 1 commit
  10. 01 May, 2013 1 commit
  11. 28 Feb, 2013 1 commit