public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: linux-xfs@vger.kernel.org
Subject: [PATCH 0/5 v2] xfs: fallocate() vs xfs_update_prealloc_flags()
Date: Tue,  1 Feb 2022 10:39:15 +1100	[thread overview]
Message-ID: <20220131233920.784181-1-david@fromorbit.com> (raw)

Hi folks,

From Darrick's original patch set:

https://lore.kernel.org/linux-xfs/164351876356.4177728.10148216594418485828.stgit@magnolia/T/#m8785dae565ff0f68ade64ca720debd483f566d6c

While auditing the file permission dropping for fallocate, I reached the
conclusion that fallocate can modify file contents, and therefore should
be treated as a file write.  As such, it needs to update the file
modification and file (metadata) change timestamps, and it needs to drop
file privileges such as setuid and capabilities, just like a regular
write.  Moreover, if the inode is configured for synchronous writes,
then all the fallocate changes really ought to be persisted to disk
before fallocate returns to userspace.

Unfortunately, the XFS fallocate implementation doesn't do this
correctly.  setgid without group-exec is a mandatory locking mark and is
left alone by write(), which means that we shouldn't drop it
unconditionally.  Furthermore, file capabilities are another vector for
setuid to be set on a program file, and XFS ignores these.

I also noticed that fallocate doesn't flush the log to disk after
fallocate when the fs is mounted with -o sync or if the DIFLAG_SYNC flag
is set on the inode.

Therefore, refactor the XFS fallocate implementation to use the VFS
helper file_modified to update file metadata instead of open-coding it
incorrectly.  Refactor it further to use xfs_file_sync_writes to decide
if we need to flush the log; and then fix the log flushing so that it
flushes after we've made /all/ the changes.

--

And from my reply:

https://lore.kernel.org/linux-xfs/164351876356.4177728.10148216594418485828.stgit@magnolia/T/#m58cedaa33368c619fcdfb53639fce881bacfa9d3

This is more along the lines of what I was thinking. Unfortunately,
xfs_fs_map_blocks() can't be made to use file based VFS helpers, so
the whole "open code the permissions stripping on data extent
allocation" thing needs to remain in that code. Otherwise, we can
significantly clean up xfs_file_fallocate() and completely remove
the entire transaction that sets the prealloc flag. And given that
xfs_ioc_space() no longer exists, most of the option functionality
that xfs_update_prealloc_flags() provides is no longer necessary...

--

This is an updated version based on 5.17-rc2 that has been run
through fstests now and there are no apparent regressions from these
changes. 

Version 2:
- add missing error handling (patch 1)
- fix whitespace damage (patch 3)
- remove redundant comments in xfs_alloc_file_space (patch 3)
- rework comments to provide context to security issues around
  PNFS operations (patch 4)



             reply	other threads:[~2022-01-31 23:39 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-31 23:39 Dave Chinner [this message]
2022-01-31 23:39 ` [PATCH 1/5] xfs: remove XFS_PREALLOC_SYNC Dave Chinner
2022-01-31 23:40   ` Darrick J. Wong
2022-01-31 23:39 ` [PATCH 2/5] xfs: fallocate() should call file_modified() Dave Chinner
2022-01-31 23:39 ` [PATCH 3/5] xfs: set prealloc flag in xfs_alloc_file_space() Dave Chinner
2022-01-31 23:39 ` [PATCH 4/5] xfs: move xfs_update_prealloc_flags() to xfs_pnfs.c Dave Chinner
2022-01-31 23:41   ` Darrick J. Wong
2022-01-31 23:39 ` [PATCH 5/5] xfs: ensure log flush at the end of a synchronous fallocate call Dave Chinner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220131233920.784181-1-david@fromorbit.com \
    --to=david@fromorbit.com \
    --cc=linux-xfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox