archive mirror
 help / color / mirror / Atom feed
From: Amir Goldstein <>
To: Miklos Szeredi <>
Cc: Jan Kara <>,
	Christian Brauner <>,
	linux-fsdevel <>,
	overlayfs <>
Subject: Re: fsnotify events for overlayfs real file
Date: Mon, 10 May 2021 19:31:56 +0300	[thread overview]
Message-ID: <> (raw)

> > > > FYI, a privileged user can already mount an overlayfs in order to indirectly
> > > > open and write to a file.
> > > >
> > > > Because overlayfs opens the underlying file FMODE_NONOTIFY this will
> > > > hide OPEN/ACCESS/MODIFY/CLOSE events also for inode/sb marks.
> > > > Since 459c7c565ac3 ("ovl: unprivieged mounts"), so can unprivileged users.
> > > >
> > > > I wonder if that is a problem that we need to fix...
> > >
> > > I assume you are speaking of the filesystem that is absorbing the changes?
> > > AFAIU usually you are not supposed to access that filesystem alone but
> > > always access it only through overlayfs and in that case you won't see the
> > > problem?
> > >
> >
> > Yes I am talking about the "backend" store for overlayfs.
> > Normally, that would be a subtree where changes are not expected
> > except through overlayfs and indeed it is documented that:
> > "If the underlying filesystem is changed, the behavior of the overlay
> >  is undefined, though it will not result in a crash or deadlock."
> > Not reporting events falls well under "undefined".
> >
> > But that is not the problem.
> > The problem is that if user A is watching a directory D for changes, then
> > an adversary user B which has read/write access to D can:
> > - Clone a userns wherein user B id is 0
> > - Mount a private overlayfs instance using D as upperdir
> > - Open file in D indirectly via private overlayfs and edit it
> >
> > So it does not require any special privileges to circumvent generating
> > events. Unless I am missing something.
> I see, right. I agree that is unfortunate especially for stuff like audit
> or fanotify permission events so we should fix that.


Do you recall what is the reason for using FMODE_NONOTIFY
for realfile?

I can see that events won't be generated anyway for watchers of
underlying file, because fsnotify_file() looks at the "fake" path
(i.e. the overlay file path).

I recently looked at a similar issue w.r.t file_remove_privs() when
I was looking at passing mnt context to notify_change() [1].

My thinking was that we can change d_real() to provide the real path:

static inline struct path d_real_path(struct path *path,
                                    const struct inode *inode)
        struct realpath = {};
        if (!unlikely(dentry->d_flags & DCACHE_OP_REAL))
               return *path;
        dentry->d_op->d_real(path->dentry, inode, &realpath);
        return realpath;

static inline struct dentry *d_real(struct dentry *dentry,
                                    const struct inode *inode)
        struct realpath = {};
        if (!unlikely(dentry->d_flags & DCACHE_OP_REAL))
               return dentry;
        dentry->d_op->d_real(path->dentry, inode, &realpath);
        return realpath.dentry;

Another option, instead of getting the realpath, just detect the
mismatch of file_inode(file) != d_inode(path->dentry) in
fanotify_file() and pass FSNOTIFY_EVENT_DENTRY data type
with d_real() dentry to backend instead of FSNOTIFY_EVENT_PATH.

For inotify it should be enough and for fanotify it is enough for
FAN_REPORT_FID and legacy fanotify can report FAN_NOFD,
so at least permission events listeners can identify the situation and
be able to block access to unknown paths.

Am I overcomplicating this?

Any magic solution that I am missing?



             reply	other threads:[~2021-05-10 16:32 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-10 16:31 Amir Goldstein [this message]
2021-05-18 14:43 ` fsnotify events for overlayfs real file Miklos Szeredi
2021-05-18 17:56   ` Amir Goldstein
2021-05-31 15:18     ` Miklos Szeredi
2021-05-31 18:26       ` Amir Goldstein
2021-06-01  9:08         ` Christian Brauner
2021-06-08 12:05         ` Marko Rauhamaa

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:

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

  git send-email \ \ \ \ \ \ \ \

* 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).