All of lore.kernel.org
 help / color / mirror / Atom feed
From: Al Viro <viro@zeniv.linux.org.uk>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: Amir Goldstein <amir73il@gmail.com>,
	Christian Brauner <brauner@kernel.org>,
	Paul Moore <paul@paul-moore.com>,
	James Morris <jmorris@namei.org>,
	"Serge E . Hallyn" <serge@hallyn.com>,
	Mimi Zohar <zohar@linux.ibm.com>,
	linux-security-module@vger.kernel.org,
	linux-integrity@vger.kernel.org, linux-unionfs@vger.kernel.org,
	linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH v3 3/3] fs: store real path instead of fake path in backing file f_path
Date: Wed, 11 Oct 2023 02:37:56 +0100	[thread overview]
Message-ID: <20231011013756.GT800259@ZenIV> (raw)
In-Reply-To: <CAJfpegtbOG0DqyuQ=xt2KDh5WDaZBb0tLJuhqa2jyQfHSMfO-w@mail.gmail.com>

On Tue, Oct 10, 2023 at 08:14:15PM +0200, Miklos Szeredi wrote:
> On Tue, 10 Oct 2023 at 19:41, Al Viro <viro@zeniv.linux.org.uk> wrote:
> >
> > On Tue, Oct 10, 2023 at 05:55:04PM +0100, Al Viro wrote:
> > > On Tue, Oct 10, 2023 at 03:34:45PM +0200, Miklos Szeredi wrote:
> > > > On Tue, 10 Oct 2023 at 15:17, Amir Goldstein <amir73il@gmail.com> wrote:
> > > >
> > > > > Sorry, you asked about ovl mount.
> > > > > To me it makes sense that if users observe ovl paths in writable mapped
> > > > > memory, that ovl should not be remounted RO.
> > > > > Anyway, I don't see a good reason to allow remount RO for ovl in that case.
> > > > > Is there?
> > > >
> > > > Agreed.
> > > >
> > > > But is preventing remount RO important enough to warrant special
> > > > casing of backing file in generic code?  I'm not convinced either
> > > > way...
> > >
> > > You definitely want to guarantee that remounting filesystem r/o
> > > prevents the changes of visible contents; it's not just POSIX,
> > > it's a fairly basic common assumption about any local filesystems.
> >
> > Incidentally, could we simply keep a reference to original struct file
> > instead of messing with path?
> >
> > The only caller of backing_file_open() gets &file->f_path as user_path; how
> > about passing file instead, and having backing_file_open() do get_file()
> > on it and stash the sucker into your object?
> >
> > And have put_file_access() do
> >         if (unlikely(file->f_mode & FMODE_BACKING))
> >                 fput(backing_file(file)->file);
> > in the end.
> 
> That's much nicer, I like it.

Won't work, unfortunately ;-/  We have the damn thing created on open();
it really can't pin the original file, or we'll never get to closing it.

I don't think this approach could be salvaged - we could make that
reference non-counting outside of mmap(), but we have no good way to
catch the moment when it should be dropped; not without intercepting
vm_ops->close() (and thus vm_ops->open() as well)...

Oh, well..

  reply	other threads:[~2023-10-11  1:38 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-09 15:37 [PATCH v3 0/3] Reduce impact of overlayfs backing files fake path Amir Goldstein
2023-10-09 15:37 ` [PATCH v3 1/3] fs: get mnt_writers count for an open backing file's real path Amir Goldstein
2023-10-09 15:37 ` [PATCH v3 2/3] fs: create helper file_user_path() for user displayed mapped file path Amir Goldstein
2023-10-09 15:37 ` [PATCH v3 3/3] fs: store real path instead of fake path in backing file f_path Amir Goldstein
2023-10-10 11:59   ` Miklos Szeredi
2023-10-10 13:10     ` Amir Goldstein
2023-10-10 13:17       ` Amir Goldstein
2023-10-10 13:34         ` Miklos Szeredi
2023-10-10 15:22           ` Amir Goldstein
2023-10-10 16:55           ` Al Viro
2023-10-10 17:41             ` Al Viro
2023-10-10 17:57               ` Amir Goldstein
2023-10-10 18:21                 ` Al Viro
2023-10-10 18:28                   ` Amir Goldstein
2023-10-11  1:26                     ` Al Viro
2023-10-10 18:14               ` Miklos Szeredi
2023-10-11  1:37                 ` Al Viro [this message]
2023-10-10 11:52 ` [PATCH v3 0/3] Reduce impact of overlayfs backing files fake path Christian Brauner

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=20231011013756.GT800259@ZenIV \
    --to=viro@zeniv.linux.org.uk \
    --cc=amir73il@gmail.com \
    --cc=brauner@kernel.org \
    --cc=jmorris@namei.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=linux-unionfs@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    --cc=paul@paul-moore.com \
    --cc=serge@hallyn.com \
    --cc=zohar@linux.ibm.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.