From: Amir Goldstein <email@example.com>
To: Miklos Szeredi <firstname.lastname@example.org>
Cc: linux-fsdevel <email@example.com>,
Vivek Goyal <firstname.lastname@example.org>
Subject: Re: overlayfs: overlapping upperdir path
Date: Thu, 1 Apr 2021 18:19:53 +0300 [thread overview]
Message-ID: <CAOQ4uxjogAWRoVBDKJ85DOW6p9BbL__tZ3ApSbGiCFsWYoJdJQ@mail.gmail.com> (raw)
On Thu, Apr 1, 2021 at 6:09 PM Miklos Szeredi <email@example.com> wrote:
> On Thu, Apr 1, 2021 at 4:30 PM Amir Goldstein <firstname.lastname@example.org> wrote:
> > On Thu, Apr 1, 2021 at 4:37 PM Miklos Szeredi <email@example.com> wrote:
> > >
> > > Commit 146d62e5a586 ("ovl: detect overlapping layers") made sure we
> > > don't have overapping layers, but it also broke the arguably valid use
> > > case of
> > >
> > > mount -olowerdir=/,upperdir=/subdir,..
> > >
> > > where subdir also resides on the root fs.
> > How is 'ls /merged/subdir' expected to behave in that use case?
> > Error?
> -ELOOP is the error returned.
> > >
> > > I also see that we check for a trap at lookup time, so the question is
> > > what does the up-front layer check buy us?
> > >
> > I'm not sure. I know it bought us silence from syzbot that started
> > mutating many overlapping layers repos....
> > Will the lookup trap have stopped it too? maybe. We did not try.
> > In general I think that if we can error out to user on mount time
> > it is preferred, but if we need to make that use case work, I'd try
> > to relax as minimum as possible from the check.
> Certainly. Like lower inside upper makes zero sense, OTOH upper
> inside lower does. So I think we just need to relax the
> upperdir/workdir layer check in this case.
> Like attached patch.
Fine by me.
Let's let syzbot have fun ;-)
prev parent reply other threads:[~2021-04-01 17:46 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-01 13:37 overlayfs: overlapping upperdir path Miklos Szeredi
2021-04-01 14:30 ` Amir Goldstein
2021-04-01 15:09 ` Miklos Szeredi
2021-04-01 15:19 ` Amir Goldstein [this message]
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).