linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Christian Brauner <brauner@kernel.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Christian Brauner <brauner@kernel.org>,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [GIT PULL] vfs: file
Date: Fri, 23 Jun 2023 13:03:18 +0200	[thread overview]
Message-ID: <20230623-waldarbeiten-normung-c160bb98bf10@brauner> (raw)

Hey Linus,

/* Summary */
This contains Amir's work to fix a long-standing problem where an
unprivileged overlayfs mount can be used to avoid fanotify permission
events that were requested for an inode or superblock on the underlying
filesystem.

Some background about files opened in overlayfs. If a file is opened in
overlayfs @file->f_path will refer to a "fake" path. What this means is
that while @file->f_inode will refer to inode of the underlying layer,
@file->f_path refers to an overlayfs {dentry,vfsmount} pair. The reasons
for doing this are out of scope here but it is the reason why the vfs
has been providing the open_with_fake_path() helper for overlayfs for
very long time now. So nothing new here.

This is for sure not very elegant and everyone including the overlayfs
maintainers agree. Improving this significantly would involve more
fragile and potentially rather invasive changes.

In various codepaths access to the path of the underlying
filesystem is needed for such hybrid file. The best example is fsnotify
where this becomes security relevant. Passing the overlayfs
@file->f_path->dentry will cause fsnotify to skip generating fsnotify
events registered on the underlying inode or superblock.

To fix this we extend the vfs provided open_with_fake_path() concept for
overlayfs to create a backing file container that holds the real path
and to expose a helper that can be used by relevant callers to get
access to the path of the underlying filesystem through the new
file_real_path() helper. This pattern is similar to what we do in
d_real() and d_real_inode().

The first beneficiary is fsnotify and fixes the security sensitive
problem mentioned above.

There's a couple of nice cleanups included as well.

Over time, the old open_with_fake_path() helper added specifically for
overlayfs a long time ago started to get used in other places such as
cachefiles. Even though cachefiles have nothing to do with hybrid files.

The only reason cachefiles used that concept was that files opened with
open_with_fake_path() aren't charged against the caller's open file
limit by raising FMODE_NOACCOUNT. It's just mere coincidence that both
overlayfs and cachefiles need to ensure to not overcharge the caller for
their internal open calls.

So this work disentangles FMODE_NOACCOUNT use cases and backing file
use-cases by adding the FMODE_BACKING flag which indicates that the file
can be used to retrieve the backing file of another filesystem. (Fyi,
Jens will be sending you a really nice cleanup from Christoph that gets
rid of 3 FMODE_* flags otherwise this would be the last fmode_t bit we'd
be using.)

So now overlayfs becomes the sole user of the renamed
open_with_fake_path() helper which is now named backing_file_open(). For
internal kernel users such as cachefiles that are only interested in
FMODE_NOACCOUNT but not in FMODE_BACKING we add a new kernel_file_open()
helper which opens a file without being charged against the caller's
open file limit. All new helpers are properly documented and clearly
annotated to mention their special uses.

We also rename vfs_tmpfile_open() to kernel_tmpfile_open() to clearly
distinguish it from vfs_tmpfile() and align it the other kernel_*()
internal helpers.

/* Testing */
clang: Ubuntu clang version 15.0.7
gcc: (Ubuntu 12.2.0-3ubuntu1) 12.2.0

All patches are based on v6.4-rc2 and have been sitting in linux-next.
No build failures or warnings were observed. All old and new tests in
fstests, selftests, and LTP pass without regressions.

/* Conflicts */
There has one merge conflict:

(1) This will cause a minor merge conflict with my v6.5/vfs.misc pull
    request as we rename an internal helper that's used in cachefiles.
    I would suggest to merge v6.5/vfs.misc first.

The following changes since commit f1fcbaa18b28dec10281551dfe6ed3a3ed80e3d6:

  Linux 6.4-rc2 (2023-05-14 12:51:40 -0700)

are available in the Git repository at:

  git@gitolite.kernel.org:pub/scm/linux/kernel/git/vfs/vfs tags/v6.5/vfs.file

for you to fetch changes up to bc2473c90fca55bf95b2ab6af1dacee26a4f92f6:

  ovl: enable fsnotify events on underlying real files (2023-06-19 18:18:04 +0200)

Please consider pulling these changes from the signed v6.5/vfs.file tag.

Thanks!
Christian

----------------------------------------------------------------
v6.5/vfs.file

----------------------------------------------------------------
Amir Goldstein (5):
      fs: rename {vfs,kernel}_tmpfile_open()
      fs: use a helper for opening kernel internal files
      fs: move kmem_cache_zalloc() into alloc_empty_file*() helpers
      fs: use backing_file container for internal files with "fake" f_path
      ovl: enable fsnotify events on underlying real files

 fs/cachefiles/namei.c    | 10 +++---
 fs/file_table.c          | 91 +++++++++++++++++++++++++++++++++++++++---------
 fs/internal.h            |  5 +--
 fs/namei.c               | 24 +++++++------
 fs/open.c                | 76 ++++++++++++++++++++++++++++++++++------
 fs/overlayfs/file.c      |  8 ++---
 fs/overlayfs/overlayfs.h |  5 +--
 include/linux/fs.h       | 42 +++++++++++++++++-----
 include/linux/fsnotify.h |  4 ++-
 9 files changed, 204 insertions(+), 61 deletions(-)

             reply	other threads:[~2023-06-23 11:04 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-23 11:03 Christian Brauner [this message]
2023-06-26 17:34 ` [GIT PULL] vfs: file pr-tracker-bot

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=20230623-waldarbeiten-normung-c160bb98bf10@brauner \
    --to=brauner@kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.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;
as well as URLs for NNTP newsgroup(s).