1. 17 Mar, 2020 1 commit
    • Miklos Szeredi's avatar
      ovl: ignore failure to copy up unknown xattrs · c61ca557
      Miklos Szeredi authored
      This issue came up with NFSv4 as the lower layer, which generates
      "system.nfs4_acl" xattrs (even for plain old unix permissions).  Prior to
      this patch this prevented copy-up from succeeding.
      
      The overlayfs permission model mandates that permissions are checked
      locally for the task and remotely for the mounter(*).  NFS4 ACLs are not
      supported by the Linux kernel currently, hence they cannot be enforced
      locally.  Which means it is indifferent whether this attribute is copied or
      not.
      
      Generalize this to any xattr that is not used in access checking (i.e. it's
      not a POSIX ACL and not in the "security." namespace).
      
      Incidentally, best effort copying of xattrs seems to also be the behavior
      of "cp -a", which is what overlayfs tries to mimic.
      
      (*) Documentation/filesystems/overlayfs.txt#Permission model
      Signed-off-by: default avatarMiklos Szeredi <mszeredi@redhat.com>
      c61ca557
  2. 22 Jan, 2020 2 commits
  3. 10 Dec, 2019 2 commits
  4. 19 Jun, 2019 1 commit
  5. 18 Jun, 2019 1 commit
    • Nicolas Schier's avatar
      ovl: fix typo in MODULE_PARM_DESC · 253e7483
      Nicolas Schier authored
      Change first argument to MODULE_PARM_DESC() calls, that each of them
      matched the actual module parameter name.  The matching results in
      changing (the 'parm' section from) the output of `modinfo overlay` from:
      
          parm: ovl_check_copy_up:Obsolete; does nothing
          parm: redirect_max:ushort
          parm: ovl_redirect_max:Maximum length of absolute redirect xattr value
          parm: redirect_dir:bool
          parm: ovl_redirect_dir_def:Default to on or off for the redirect_dir feature
          parm: redirect_always_follow:bool
          parm: ovl_redirect_always_follow:Follow redirects even if redirect_dir feature is turned off
          parm: index:bool
          parm: ovl_index_def:Default to on or off for the inodes index feature
          parm: nfs_export:bool
          parm: ovl_nfs_export_def:Default to on or off for the NFS export feature
          parm: xino_auto:bool
          parm: ovl_xino_auto_def:Auto enable xino feature
          parm: metacopy:bool
          parm: ovl_metacopy_def:Default to on or off for the metadata only copy up feature
      
      into:
      
          parm: check_copy_up:Obsolete; does nothing
          parm: redirect_max:Maximum length of absolute redirect xattr value (ushort)
          parm: redirect_dir:Default to on or off for the redirect_dir feature (bool)
          parm: redirect_always_follow:Follow redirects even if redirect_dir feature is turned off (bool)
          parm: index:Default to on or off for the inodes index feature (bool)
          parm: nfs_export:Default to on or off for the NFS export feature (bool)
          parm: xino_auto:Auto enable xino feature (bool)
          parm: metacopy:Default to on or off for the metadata only copy up feature (bool)
      Signed-off-by: default avatarNicolas Schier <n.schier@avm.de>
      Signed-off-by: default avatarMiklos Szeredi <mszeredi@redhat.com>
      253e7483
  6. 06 May, 2019 1 commit
    • Amir Goldstein's avatar
      ovl: fix missing upper fs freeze protection on copy up for ioctl · 3428030d
      Amir Goldstein authored
      Generalize the helper ovl_open_maybe_copy_up() and use it to copy up file
      with data before FS_IOC_SETFLAGS ioctl.
      
      The FS_IOC_SETFLAGS ioctl is a bit of an odd ball in vfs, which probably
      caused the confusion.  File may be open O_RDONLY, but ioctl modifies the
      file.  VFS does not call mnt_want_write_file() nor lock inode mutex, but
      fs-specific code for FS_IOC_SETFLAGS does.  So ovl_ioctl() calls
      mnt_want_write_file() for the overlay file, and fs-specific code calls
      mnt_want_write_file() for upper fs file, but there was no call for
      ovl_want_write() for copy up duration which prevents overlayfs from copying
      up on a frozen upper fs.
      
      Fixes: dab5ca8f ("ovl: add lsattr/chattr support")
      Cc: <stable@vger.kernel.org> # v4.19
      Signed-off-by: default avatarAmir Goldstein <amir73il@gmail.com>
      Acked-by: default avatarVivek Goyal <vgoyal@redhat.com>
      Signed-off-by: default avatarMiklos Szeredi <mszeredi@redhat.com>
      3428030d
  7. 13 Feb, 2019 1 commit
  8. 04 Feb, 2019 1 commit
    • Vivek Goyal's avatar
      ovl: During copy up, first copy up data and then xattrs · 5f32879e
      Vivek Goyal authored
      If a file with capability set (and hence security.capability xattr) is
      written kernel clears security.capability xattr. For overlay, during file
      copy up if xattrs are copied up first and then data is, copied up. This
      means data copy up will result in clearing of security.capability xattr
      file on lower has. And this can result into surprises. If a lower file has
      CAP_SETUID, then it should not be cleared over copy up (if nothing was
      actually written to file).
      
      This also creates problems with chown logic where it first copies up file
      and then tries to clear setuid bit. But by that time security.capability
      xattr is already gone (due to data copy up), and caller gets -ENODATA.
      This has been reported by Giuseppe here.
      
      https://github.com/containers/libpod/issues/2015#issuecomment-447824842
      
      Fix this by copying up data first and then metadta. This is a regression
      which has been introduced by my commit as part of metadata only copy up
      patches.
      
      TODO: There will be some corner cases where a file is copied up metadata
      only and later data copy up happens and that will clear security.capability
      xattr. Something needs to be done about that too.
      
      Fixes: bd64e575 ("ovl: During copy up, first copy up metadata and then data")
      Cc: <stable@vger.kernel.org> # v4.19+
      Reported-by: default avatarGiuseppe Scrivano <gscrivan@redhat.com>
      Signed-off-by: default avatarVivek Goyal <vgoyal@redhat.com>
      Signed-off-by: default avatarMiklos Szeredi <mszeredi@redhat.com>
      5f32879e
  9. 29 Oct, 2018 2 commits
  10. 26 Oct, 2018 3 commits
  11. 24 Sep, 2018 1 commit
    • Amir Goldstein's avatar
      vfs: swap names of {do,vfs}_clone_file_range() · a725356b
      Amir Goldstein authored
      Commit 031a072a ("vfs: call vfs_clone_file_range() under freeze
      protection") created a wrapper do_clone_file_range() around
      vfs_clone_file_range() moving the freeze protection to former, so
      overlayfs could call the latter.
      
      The more common vfs practice is to call do_xxx helpers from vfs_xxx
      helpers, where freeze protecction is taken in the vfs_xxx helper, so
      this anomality could be a source of confusion.
      
      It seems that commit 8ede2055 ("ovl: add reflink/copyfile/dedup
      support") may have fallen a victim to this confusion -
      ovl_clone_file_range() calls the vfs_clone_file_range() helper in the
      hope of getting freeze protection on upper fs, but in fact results in
      overlayfs allowing to bypass upper fs freeze protection.
      
      Swap the names of the two helpers to conform to common vfs practice
      and call the correct helpers from overlayfs and nfsd.
      Signed-off-by: default avatarAmir Goldstein <amir73il@gmail.com>
      Signed-off-by: default avatarMiklos Szeredi <mszeredi@redhat.com>
      a725356b
  12. 20 Jul, 2018 8 commits
  13. 18 Jul, 2018 1 commit
  14. 31 May, 2018 5 commits
  15. 12 Apr, 2018 1 commit
  16. 24 Jan, 2018 5 commits
  17. 09 Nov, 2017 2 commits
  18. 05 Oct, 2017 1 commit
  19. 14 Sep, 2017 1 commit
    • Michal Hocko's avatar
      mm: treewide: remove GFP_TEMPORARY allocation flag · 0ee931c4
      Michal Hocko authored
      GFP_TEMPORARY was introduced by commit e12ba74d ("Group short-lived
      and reclaimable kernel allocations") along with __GFP_RECLAIMABLE.  It's
      primary motivation was to allow users to tell that an allocation is
      short lived and so the allocator can try to place such allocations close
      together and prevent long term fragmentation.  As much as this sounds
      like a reasonable semantic it becomes much less clear when to use the
      highlevel GFP_TEMPORARY allocation flag.  How long is temporary? Can the
      context holding that memory sleep? Can it take locks? It seems there is
      no good answer for those questions.
      
      The current implementation of GFP_TEMPORARY is basically GFP_KERNEL |
      __GFP_RECLAIMABLE which in itself is tricky because basically none of
      the existing caller provide a way to reclaim the allocated memory.  So
      this is rather misleading and hard to evaluate for any benefits.
      
      I have checked some random users and none of them has added the flag
      with a specific justification.  I suspect most of them just copied from
      other existing users and others just thought it might be a good idea to
      use without any measuring.  This suggests that GFP_TEMPORARY just
      motivates for cargo cult usage without any reasoning.
      
      I believe that our gfp flags are quite complex already and especially
      those with highlevel semantic should be clearly defined to prevent from
      confusion and abuse.  Therefore I propose dropping GFP_TEMPORARY and
      replace all existing users to simply use GFP_KERNEL.  Please note that
      SLAB users with shrinkers will still get __GFP_RECLAIMABLE heuristic and
      so they will be placed properly for memory fragmentation prevention.
      
      I can see reasons we might want some gfp flag to reflect shorterm
      allocations but I propose starting from a clear semantic definition and
      only then add users with proper justification.
      
      This was been brought up before LSF this year by Matthew [1] and it
      turned out that GFP_TEMPORARY really doesn't have a clear semantic.  It
      seems to be a heuristic without any measured advantage for most (if not
      all) its current users.  The follow up discussion has revealed that
      opinions on what might be temporary allocation differ a lot between
      developers.  So rather than trying to tweak existing users into a
      semantic which they haven't expected I propose to simply remove the flag
      and start from scratch if we really need a semantic for short term
      allocations.
      
      [1] http://lkml.kernel.org/r/20170118054945.GD18349@bombadil.infradead.org
      
      [akpm@linux-foundation.org: fix typo]
      [akpm@linux-foundation.org: coding-style fixes]
      [sfr@canb.auug.org.au: drm/i915: fix up]
        Link: http://lkml.kernel.org/r/20170816144703.378d4f4d@canb.auug.org.au
      Link: http://lkml.kernel.org/r/20170728091904.14627-1-mhocko@kernel.orgSigned-off-by: default avatarMichal Hocko <mhocko@suse.com>
      Signed-off-by: default avatarStephen Rothwell <sfr@canb.auug.org.au>
      Acked-by: default avatarMel Gorman <mgorman@suse.de>
      Acked-by: default avatarVlastimil Babka <vbabka@suse.cz>
      Cc: Matthew Wilcox <willy@infradead.org>
      Cc: Neil Brown <neilb@suse.de>
      Cc: "Theodore Ts'o" <tytso@mit.edu>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      0ee931c4