Skip to content
Snippets Groups Projects
  1. Apr 12, 2021
  2. Jan 28, 2021
    • Sargun Dhillon's avatar
      ovl: implement volatile-specific fsync error behaviour · 335d3fc5
      Sargun Dhillon authored
      
      Overlayfs's volatile option allows the user to bypass all forced sync calls
      to the upperdir filesystem. This comes at the cost of safety. We can never
      ensure that the user's data is intact, but we can make a best effort to
      expose whether or not the data is likely to be in a bad state.
      
      The best way to handle this in the time being is that if an overlayfs's
      upperdir experiences an error after a volatile mount occurs, that error
      will be returned on fsync, fdatasync, sync, and syncfs. This is
      contradictory to the traditional behaviour of VFS which fails the call
      once, and only raises an error if a subsequent fsync error has occurred,
      and been raised by the filesystem.
      
      One awkward aspect of the patch is that we have to manually set the
      superblock's errseq_t after the sync_fs callback as opposed to just
      returning an error from syncfs. This is because the call chain looks
      something like this:
      
      sys_syncfs ->
      	sync_filesystem ->
      		__sync_filesystem ->
      			/* The return value is ignored here
      			sb->s_op->sync_fs(sb)
      			_sync_blockdev
      		/* Where the VFS fetches the error to raise to userspace */
      		errseq_check_and_advance
      
      Because of this we call errseq_set every time the sync_fs callback occurs.
      Due to the nature of this seen / unseen dichotomy, if the upperdir is an
      inconsistent state at the initial mount time, overlayfs will refuse to
      mount, as overlayfs cannot get a snapshot of the upperdir's errseq that
      will increment on error until the user calls syncfs.
      
      Signed-off-by: default avatarSargun Dhillon <sargun@sargun.me>
      Suggested-by: default avatarAmir Goldstein <amir73il@gmail.com>
      Reviewed-by: default avatarAmir Goldstein <amir73il@gmail.com>
      Fixes: c86243b0 ("ovl: provide a mount option "volatile"")
      Cc: stable@vger.kernel.org
      Reviewed-by: default avatarVivek Goyal <vgoyal@redhat.com>
      Reviewed-by: default avatarJeff Layton <jlayton@kernel.org>
      Signed-off-by: default avatarMiklos Szeredi <mszeredi@redhat.com>
      335d3fc5
  3. Jan 24, 2021
  4. Dec 14, 2020
    • Miklos Szeredi's avatar
      ovl: do not get metacopy for userxattr · 87b2c60c
      Miklos Szeredi authored
      
      When looking up an inode on the lower layer for which the mounter lacks
      read permisison the metacopy check will fail.  This causes the lookup to
      fail as well, even though the directory is readable.
      
      So ignore EACCES for the "userxattr" case and assume no metacopy for the
      unreadable file.
      
      Signed-off-by: default avatarMiklos Szeredi <mszeredi@redhat.com>
      87b2c60c
    • Miklos Szeredi's avatar
      ovl: user xattr · 2d2f2d73
      Miklos Szeredi authored
      
      Optionally allow using "user.overlay." namespace instead of
      "trusted.overlay."
      
      This is necessary for overlayfs to be able to be mounted in an unprivileged
      namepsace.
      
      Make the option explicit, since it makes the filesystem format be
      incompatible.
      
      Disable redirect_dir and metacopy options, because these would allow
      privilege escalation through direct manipulation of the
      "user.overlay.redirect" or "user.overlay.metacopy" xattrs.
      
      Signed-off-by: default avatarMiklos Szeredi <mszeredi@redhat.com>
      Reviewed-by: default avatarAmir Goldstein <amir73il@gmail.com>
      2d2f2d73
    • Miklos Szeredi's avatar
      ovl: check privs before decoding file handle · c846af05
      Miklos Szeredi authored
      
      CAP_DAC_READ_SEARCH is required by open_by_handle_at(2) so check it in
      ovl_decode_real_fh() as well to prevent privilege escalation for
      unprivileged overlay mounts.
      
      [Amir] If the mounter is not capable in init ns, ovl_check_origin() and
      ovl_verify_index() will not function as expected and this will break index
      and nfs export features.  So check capability in ovl_can_decode_fh(), to
      auto disable those features.
      
      Signed-off-by: default avatarMiklos Szeredi <mszeredi@redhat.com>
      c846af05
  5. Nov 12, 2020
  6. Sep 02, 2020
  7. Jun 04, 2020
  8. Jun 02, 2020
    • Miklos Szeredi's avatar
      ovl: verify permissions in ovl_path_open() · 56230d95
      Miklos Szeredi authored
      
      Check permission before opening a real file.
      
      ovl_path_open() is used by readdir and copy-up routines.
      
      ovl_permission() theoretically already checked copy up permissions, but it
      doesn't hurt to re-do these checks during the actual copy-up.
      
      For directory reading ovl_permission() only checks access to topmost
      underlying layer.  Readdir on a merged directory accesses layers below the
      topmost one as well.  Permission wasn't checked for these layers.
      
      Note: modifying ovl_permission() to perform this check would be far more
      complex and hence more bug prone.  The result is less precise permissions
      returned in access(2).  If this turns out to be an issue, we can revisit
      this bug.
      
      Signed-off-by: default avatarMiklos Szeredi <mszeredi@redhat.com>
      56230d95
  9. May 13, 2020
  10. Mar 17, 2020
  11. Mar 12, 2020
  12. Jan 24, 2020
  13. Jan 22, 2020
  14. Jun 19, 2019
  15. May 29, 2019
    • Amir Goldstein's avatar
      ovl: detect overlapping layers · 146d62e5
      Amir Goldstein authored
      Overlapping overlay layers are not supported and can cause unexpected
      behavior, but overlayfs does not currently check or warn about these
      configurations.
      
      User is not supposed to specify the same directory for upper and
      lower dirs or for different lower layers and user is not supposed to
      specify directories that are descendants of each other for overlay
      layers, but that is exactly what this zysbot repro did:
      
          https://syzkaller.appspot.com/x/repro.syz?x=12c7a94f400000
      
      
      
      Moving layer root directories into other layers while overlayfs
      is mounted could also result in unexpected behavior.
      
      This commit places "traps" in the overlay inode hash table.
      Those traps are dummy overlay inodes that are hashed by the layers
      root inodes.
      
      On mount, the hash table trap entries are used to verify that overlay
      layers are not overlapping.  While at it, we also verify that overlay
      layers are not overlapping with directories "in-use" by other overlay
      instances as upperdir/workdir.
      
      On lookup, the trap entries are used to verify that overlay layers
      root inodes have not been moved into other layers after mount.
      
      Some examples:
      
      $ ./run --ov --samefs -s
      ...
      ( mkdir -p base/upper/0/u base/upper/0/w base/lower lower upper mnt
        mount -o bind base/lower lower
        mount -o bind base/upper upper
        mount -t overlay none mnt ...
              -o lowerdir=lower,upperdir=upper/0/u,workdir=upper/0/w)
      
      $ umount mnt
      $ mount -t overlay none mnt ...
              -o lowerdir=base,upperdir=upper/0/u,workdir=upper/0/w
      
        [   94.434900] overlayfs: overlapping upperdir path
        mount: mount overlay on mnt failed: Too many levels of symbolic links
      
      $ mount -t overlay none mnt ...
              -o lowerdir=upper/0/u,upperdir=upper/0/u,workdir=upper/0/w
      
        [  151.350132] overlayfs: conflicting lowerdir path
        mount: none is already mounted or mnt busy
      
      $ mount -t overlay none mnt ...
              -o lowerdir=lower:lower/a,upperdir=upper/0/u,workdir=upper/0/w
      
        [  201.205045] overlayfs: overlapping lowerdir path
        mount: mount overlay on mnt failed: Too many levels of symbolic links
      
      $ mount -t overlay none mnt ...
              -o lowerdir=lower,upperdir=upper/0/u,workdir=upper/0/w
      $ mv base/upper/0/ base/lower/
      $ find mnt/0
        mnt/0
        mnt/0/w
        find: 'mnt/0/w/work': Too many levels of symbolic links
        find: 'mnt/0/u': Too many levels of symbolic links
      
      Reported-by: default avatar <syzbot+9c69c282adc4edd2b540@syzkaller.appspotmail.com>
      Signed-off-by: default avatarAmir Goldstein <amir73il@gmail.com>
      Signed-off-by: default avatarMiklos Szeredi <mszeredi@redhat.com>
      146d62e5
  16. Feb 13, 2019
  17. Oct 26, 2018
  18. Sep 24, 2018
  19. Jul 20, 2018
    • Vivek Goyal's avatar
      ovl: Check redirect on index as well · 0a2d0d3f
      Vivek Goyal authored
      
      Right now we seem to check redirect only if upperdentry is found.  But it
      is possible that there is no upperdentry but later we found an index.
      
      We need to check redirect on index as well and set it in
      ovl_inode->redirect.  Otherwise link code can assume that dentry does not
      have redirect and place a new one which breaks things.  In my testing
      overlay/033 test started failing in xfstests.  Following are the details.
      
      For example do following.
      
      $ mkdir lower upper work merged
      
       - Make lower dir with 4 links.
        $ echo "foo" > lower/l0.txt
        $ ln  lower/l0.txt lower/l1.txt
        $ ln  lower/l0.txt lower/l2.txt
        $ ln  lower/l0.txt lower/l3.txt
      
       - Mount with index on and metacopy on.
      
        $ mount -t overlay -o lowerdir=lower,upperdir=upper,workdir=work,\
                              index=on,metacopy=on none merged
      
       - Link lower
      
        $ ln merged/l0.txt merged/l4.txt
          (This will metadata copy up of l0.txt and put an absolute redirect
           /l0.txt)
      
        $ echo 2 > /proc/sys/vm/drop/caches
      
        $ ls merged/l1.txt
        (Now l1.txt will be looked up.  There is no upper dentry but there is
         lower dentry and index will be found.  We don't check for redirect on
         index, hence ovl_inode->redirect will be NULL.)
      
       - Link Upper
      
        $ ln merged/l4.txt merged/l5.txt
        (Lookup of l4.txt will use inode from l1.txt lookup which is still in
         cache.  It has ovl_inode->redirect NULL, hence link will put a new
         redirect and replace /l0.txt with /l4.txt
      
       - Drop caches.
        echo 2 > /proc/sys/vm/drop_caches
      
       - List l1.txt and it returns -ESTALE
      
        $ ls merged/l0.txt
      
        (It returns stale because, we found a metacopy of l0.txt in upper and it
         has redirect l4.txt but there is no file named l4.txt in lower layer.
         So lower data copy is not found and -ESTALE is returned.)
      
      So problem here is that we did not process redirect on index.  Check
      redirect on index as well and then problem is fixed.
      
      Signed-off-by: default avatarVivek Goyal <vgoyal@redhat.com>
      Reviewed-by: default avatarAmir Goldstein <amir73il@gmail.com>
      Signed-off-by: default avatarMiklos Szeredi <mszeredi@redhat.com>
      0a2d0d3f
    • Vivek Goyal's avatar
      ovl: Do not set dentry type ORIGIN for broken hardlinks · 60124877
      Vivek Goyal authored
      
      If a dentry has copy up origin, we set flag OVL_PATH_ORIGIN.  So far this
      decision was easy that we had to check only for oe->numlower and if it is
      non-zero, we knew there is copy up origin.  (For non-dir we installed
      origin dentry in lowerstack[0]).
      
      But we don't create ORGIN xattr for broken hardlinks (index=off).  And with
      metacopy feature it is possible that we will install lowerstack[0] but
      ORIGIN xattr is not there.  It is data dentry of upper metacopy dentry
      which has been found using regular name based lookup or using REDIRECT.  So
      with addition of this new case, just presence of oe->numlower is not
      sufficient to guarantee that ORIGIN xattr is present.
      
      So to differentiate between two cases, look at OVL_CONST_INO flag.  If this
      flag is set and upperdentry is there, that means it can be marked as type
      ORIGIN.  OVL_CONST_INO is not set if lower hardlink is broken or will be
      broken over copy up.
      
      Signed-off-by: default avatarVivek Goyal <vgoyal@redhat.com>
      Reviewed-by: default avatarAmir Goldstein <amir73il@gmail.com>
      Signed-off-by: default avatarMiklos Szeredi <mszeredi@redhat.com>
      60124877
    • Vivek Goyal's avatar
      ovl: Treat metacopy dentries as type OVL_PATH_MERGE · 0b17c28a
      Vivek Goyal authored
      
      Right now OVL_PATH_MERGE is used only for merged directories.  But
      conceptually, a metacopy dentry (backed by a lower data dentry) is a merged
      entity as well.
      
      So mark metacopy dentries as OVL_PATH_MERGE and ovl_rename() makes use of
      this property later to set redirect on a metacopy file.
      
      Signed-off-by: default avatarVivek Goyal <vgoyal@redhat.com>
      Reviewed-by: default avatarAmir Goldstein <amir73il@gmail.com>
      Signed-off-by: default avatarMiklos Szeredi <mszeredi@redhat.com>
      0b17c28a
    • Vivek Goyal's avatar
      ovl: Add helper ovl_inode_realdata() · 4823d49c
      Vivek Goyal authored
      
      Add an helper to retrieve real data inode associated with overlay inode.
      This helper will ignore all metacopy inodes and will return only the real
      inode which has data.
      
      Signed-off-by: default avatarVivek Goyal <vgoyal@redhat.com>
      Reviewed-by: default avatarAmir Goldstein <amir73il@gmail.com>
      Signed-off-by: default avatarMiklos Szeredi <mszeredi@redhat.com>
      4823d49c
    • Vivek Goyal's avatar
      ovl: Store lower data inode in ovl_inode · 2664bd08
      Vivek Goyal authored
      
      Right now ovl_inode stores inode pointer for lower inode.  This helps with
      quickly getting lower inode given overlay inode (ovl_inode_lower()).
      
      Now with metadata only copy-up, we can have metacopy inode in middle layer
      as well and inode containing data can be different from ->lower.  I need to
      be able to open the real file in ovl_open_realfile() and for that I need to
      quickly find the lower data inode.
      
      Hence store lower data inode also in ovl_inode.  Also provide an helper
      ovl_inode_lowerdata() to access this field.
      
      Signed-off-by: default avatarVivek Goyal <vgoyal@redhat.com>
      Reviewed-by: default avatarAmir Goldstein <amir73il@gmail.com>
      Signed-off-by: default avatarMiklos Szeredi <mszeredi@redhat.com>
      2664bd08
    • Vivek Goyal's avatar
      ovl: Fix ovl_getattr() to get number of blocks from lower · 67d756c2
      Vivek Goyal authored
      
      If an inode has been copied up metadata only, then we need to query the
      number of blocks from lower and fill up the stat->st_blocks.
      
      We need to be careful about races where we are doing stat on one cpu and
      data copy up is taking place on other cpu.  We want to return
      stat->st_blocks either from lower or stable upper and not something in
      between.  Hence, ovl_has_upperdata() is called first to figure out whether
      block reporting will take place from lower or upper.
      
      We now support metacopy dentries in middle layer.  That means number of
      blocks reporting needs to come from lowest data dentry and this could be
      different from lower dentry.  Hence we end up making a separate
      vfs_getxattr() call for metacopy dentries to get number of blocks.
      
      Signed-off-by: default avatarVivek Goyal <vgoyal@redhat.com>
      Reviewed-by: default avatarAmir Goldstein <amir73il@gmail.com>
      Signed-off-by: default avatarMiklos Szeredi <mszeredi@redhat.com>
      67d756c2
Loading