> > > > 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.
>
Miklos,
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?
Thanks,
Amir.
[1] https://lore.kernel.org/linux-fsdevel/CAOQ4uxiWb5Auyrbrj44hvdMcvMhx1YPRrR90RkicntmyfF+Ugw@xxxxxxxxxxxxxx/
