1. 14 Mar, 2022 4 commits
    • Darrick J. Wong's avatar
      xfs: reserve quota for target dir expansion when renaming files · 41667260
      Darrick J. Wong authored
      XFS does not reserve quota for directory expansion when renaming
      children into a directory.  This means that we don't reject the
      expansion with EDQUOT when we're at or near a hard limit, which means
      that unprivileged userspace can use rename() to exceed quota.
      
      Rename operations don't always expand the target directory, and we allow
      a rename to proceed with no space reservation if we don't need to add a
      block to the target directory to handle the addition.  Moreover, the
      unlink operation on the source directory generally does not expand the
      directory (you'd have to free a block and then cause a btree split) and
      it's probably of little consequence to leave the corner case that
      renaming a file out of a directory can increase its size.
      
      As with link and unlink, there is a further bug in that we do not
      trigger the blockgc workers to try to clear space when we're out of
      quota.
      
      Because rename is its own special tricky animal, we'll patch xfs_rename
      directly to reserve quota to the rename transaction.  We'll leave
      cleaning up the rest of xfs_rename for the metadata directory tree
      patchset.
      Signed-off-by: default avatarDarrick J. Wong <djwong@kernel.org>
      Reviewed-by: default avatarDave Chinner <dchinner@redhat.com>
      41667260
    • Darrick J. Wong's avatar
      xfs: reserve quota for dir expansion when linking/unlinking files · 871b9316
      Darrick J. Wong authored
      XFS does not reserve quota for directory expansion when linking or
      unlinking children from a directory.  This means that we don't reject
      the expansion with EDQUOT when we're at or near a hard limit, which
      means that unprivileged userspace can use link()/unlink() to exceed
      quota.
      
      The fix for this is nuanced -- link operations don't always expand the
      directory, and we allow a link to proceed with no space reservation if
      we don't need to add a block to the directory to handle the addition.
      Unlink operations generally do not expand the directory (you'd have to
      free a block and then cause a btree split) and we can defer the
      directory block freeing if there is no space reservation.
      
      Moreover, there is a further bug in that we do not trigger the blockgc
      workers to try to clear space when we're out of quota.
      
      To fix both cases, create a new xfs_trans_alloc_dir function that
      allocates the transaction, locks and joins the inodes, and reserves
      quota for the directory.  If there isn't sufficient space or quota,
      we'll switch the caller to reservationless mode.  This should prevent
      quota usage overruns with the least restriction in functionality.
      Signed-off-by: default avatarDarrick J. Wong <djwong@kernel.org>
      Reviewed-by: default avatarDave Chinner <dchinner@redhat.com>
      871b9316
    • Darrick J. Wong's avatar
      xfs: refactor user/group quota chown in xfs_setattr_nonsize · dd3b015d
      Darrick J. Wong authored
      Combine if tests to reduce the indentation levels of the quota chown
      calls in xfs_setattr_nonsize.
      Signed-off-by: default avatarDarrick J. Wong <djwong@kernel.org>
      Reviewed-by: default avatarDave Chinner <dchinner@redhat.com>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Reviewed-by: default avatarChristian Brauner <brauner@kernel.org>
      dd3b015d
    • Darrick J. Wong's avatar
      xfs: use setattr_copy to set vfs inode attributes · e014f37d
      Darrick J. Wong authored
      Filipe Manana pointed out that XFS' behavior w.r.t. setuid/setgid
      revocation isn't consistent with btrfs[1] or ext4.  Those two
      filesystems use the VFS function setattr_copy to convey certain
      attributes from struct iattr into the VFS inode structure.
      
      Andrey Zhadchenko reported[2] that XFS uses the wrong user namespace to
      decide if it should clear setgid and setuid on a file attribute update.
      This is a second symptom of the problem that Filipe noticed.
      
      XFS, on the other hand, open-codes setattr_copy in xfs_setattr_mode,
      xfs_setattr_nonsize, and xfs_setattr_time.  Regrettably, setattr_copy is
      /not/ a simple copy function; it contains additional logic to clear the
      setgid bit when setting the mode, and XFS' version no longer matches.
      
      The VFS implements its own setuid/setgid stripping logic, which
      establishes consistent behavior.  It's a tad unfortunate that it's
      scattered across notify_change, should_remove_suid, and setattr_copy but
      XFS should really follow the Linux VFS.  Adapt XFS to use the VFS
      functions and get rid of the old functions.
      
      [1] https://lore.kernel.org/fstests/CAL3q7H47iNQ=Wmk83WcGB-KBJVOEtR9+qGczzCeXJ9Y2KCV25Q@mail.gmail.com/
      [2] https://lore.kernel.org/linux-xfs/20220221182218.748084-1-andrey.zhadchenko@virtuozzo.com/
      
      Fixes: 7fa294c8 ("userns: Allow chown and setgid preservation")
      Signed-off-by: default avatarDarrick J. Wong <djwong@kernel.org>
      Reviewed-by: default avatarDave Chinner <dchinner@redhat.com>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Reviewed-by: default avatarChristian Brauner <brauner@kernel.org>
      e014f37d
  2. 09 Mar, 2022 2 commits
  3. 27 Feb, 2022 4 commits
  4. 26 Feb, 2022 22 commits
  5. 25 Feb, 2022 8 commits