linux-unionfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Vivek Goyal <vgoyal@redhat.com>
To: Amir Goldstein <amir73il@gmail.com>
Cc: Miklos Szeredi <miklos@szeredi.hu>,
	overlayfs <linux-unionfs@vger.kernel.org>
Subject: Re: [PATCH 0/3] Misc. redirect_dir=nofollow fixes
Date: Wed, 15 Jul 2020 09:06:48 -0400	[thread overview]
Message-ID: <20200715130648.GA379396@redhat.com> (raw)
In-Reply-To: <CAOQ4uxh-fUKhiQOhRmZ5LT2sjtM3Wx5wo_wcKYtX+-DbYjXp0Q@mail.gmail.com>

On Tue, Jul 14, 2020 at 09:42:53PM +0300, Amir Goldstein wrote:
> On Tue, Jul 14, 2020 at 9:07 PM Vivek Goyal <vgoyal@redhat.com> wrote:
> >
> > On Mon, Jul 13, 2020 at 05:19:42PM +0300, Amir Goldstein wrote:
> > > Miklos, Vivek,
> > >
> > > Following discussion on following an unsafe non-dir origin [1]
> > > and in a addition to a fix for the reported null uuid case [2] and to
> > > Vivek's doc clarification [3], I am proposing to piggy back existing
> > > config redirect_dir=nofollow to also not follow non-dir origin.
> > >
> > > Like in the case of non-dir origin, following redirects behavior was
> > > added with no opt-out option in kernel v4.10.  Later security concerns
> > > about following malformed redirects resulted in the redirect_dir=nofollow
> > > config option.
> >
> > So what's the security issue you are seeing with malformed origin? If
> 
> TBH I never really understood the thread that led to redirect_dir=nofollow.
> I don't think anyone has presented a proper use case that can be discussed,

IIUC, idea was that automated mounting can mount a handcrafted upper on
usb hence allow access to directories on host which are otherwise
inaccessible. 

> so I just treat this config option as "paranoia" or "don't give me anything that
> very old overlay did not give me".
> Therefore I suggested piggybacking on it.

Even if it is paranoia, put more unrelated checks under this option does
not make much sense to me. It will make things just more confusing.

Anyway, redirect_dir=nofollow is a thing of past. Now if you want to
not follow origin, then we first need to have a genuine explanation
of why to do that (and not be driven by just paranoia).

> Of course if we do, we will need to document that.

redirect_dir=nofollow resulting in origin not being followed is plain
unintuitive to me. Why not introduce another option if not following
origin is so important.

Thanks
Vivek

> BTW, I have another patch that does not follow mismatched lower dir origin
> with redirect_dir=nofollow, i.e.:
> 
>  bool ovl_verify_lower(struct super_block *sb)
>  {
>         struct ovl_fs *ofs = sb->s_fs_info;
> 
> -       return ofs->config.nfs_export && ofs->config.index;
> +       return ofs->config.nfs_export || !ofs->config.redirect_follow;
>  }
> 
> That makes even more sense for "paranoia" IMO.
> 
> Thanks,
> Amir.
> 


  reply	other threads:[~2020-07-15 13:06 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-13 14:19 [PATCH 0/3] Misc. redirect_dir=nofollow fixes Amir Goldstein
2020-07-13 14:19 ` [PATCH 1/3] ovl: force read-only sb on failure to create index dir Amir Goldstein
2020-07-14 18:18   ` Vivek Goyal
2020-07-14 18:32     ` Amir Goldstein
2020-07-14 18:38       ` Vivek Goyal
2020-07-14 18:45         ` Amir Goldstein
2020-07-15 20:04         ` Miklos Szeredi
2020-07-16  5:00           ` Amir Goldstein
2020-07-15 20:03   ` Miklos Szeredi
2020-07-13 14:19 ` [PATCH 2/3] ovl: fix mount option checks for nfs_export with no upperdir Amir Goldstein
2020-07-14 14:52   ` Miklos Szeredi
2020-07-14 14:58     ` Amir Goldstein
2020-07-14 15:08       ` Miklos Szeredi
2020-07-14 15:20         ` Amir Goldstein
2020-07-15 20:05   ` Miklos Szeredi
2020-07-13 14:19 ` [PATCH 3/3] ovl: do not follow non-dir origin with redirect_dir=nofollow Amir Goldstein
2020-10-30 12:05   ` Miklos Szeredi
2020-10-30 13:20     ` Amir Goldstein
2020-10-30 13:51       ` Miklos Szeredi
2020-07-14 18:07 ` [PATCH 0/3] Misc. redirect_dir=nofollow fixes Vivek Goyal
2020-07-14 18:42   ` Amir Goldstein
2020-07-15 13:06     ` Vivek Goyal [this message]
2020-07-15 13:56       ` Amir Goldstein
2020-07-16 13:27         ` Vivek Goyal
2020-07-16 13:43           ` Amir Goldstein
2020-07-16 15:26             ` Vivek Goyal

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=20200715130648.GA379396@redhat.com \
    --to=vgoyal@redhat.com \
    --cc=amir73il@gmail.com \
    --cc=linux-unionfs@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    /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).