($INBOX_DIR/description missing)
 help / color / 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: Thu, 16 Jul 2020 11:26:14 -0400
Message-ID: <20200716152614.GD422759@redhat.com> (raw)
In-Reply-To: <CAOQ4uxhZ0kx-c_nkP8Njf2ZMY4d2RvWQH0A0gShmA_w3TLzbcQ@mail.gmail.com>

On Thu, Jul 16, 2020 at 04:43:22PM +0300, Amir Goldstein wrote:
> On Thu, Jul 16, 2020 at 4:27 PM Vivek Goyal <vgoyal@redhat.com> wrote:
> >
> > On Wed, Jul 15, 2020 at 04:56:45PM +0300, Amir Goldstein wrote:
> > > > > 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.
> > > >
> > >
> > > That is an *idea* described by hand waving.
> > > That is not a threat I can seriously comment on.
> > > How exactly is that USB auto mounted? where to?
> > > How is that related to overlay?
> > >
> > > > > 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.
> > > >
> > >
> > > Because cluttering the user with more and more config options for
> > > minor and mostly unimportant behaviors is not ideal either.
> > > See what Kconfig help has to say about the config option:
> > >
> > > config OVERLAY_FS_REDIRECT_ALWAYS_FOLLOW
> > >         bool "Overlayfs: follow redirects even if redirects are turned off"
> > >         default y
> > >
> > >        Disable this to get a possibly more secure configuration, but that
> > >        might not be backward compatible with previous kernels.
> > >
> > > That is a VERY generic description that fits not following origin very
> > > well IMO, and not following unverified dir origin as well for that matter.
> > > Nobody outside overlayfs developers knows what "redirects" means
> > > anyway. To me, following non-dir origin sounds exactly the same
> > > as following non-dir metacopy redirect or dir redirect. It's just the
> > > implementation details that differ.
> > >
> > > So my claim is that we *can* piggyback on it because I really
> > > don't believe anybody is using this config out there for anything
> > > other than "to be on the safe side".
> >
> > On one hand you are saying redirect=nofollow is paranoia, most people
> > don't understand it and don't use it. And on top of that you want
> > to add more to it. Adding more to something which nobody does not
> > understand and uses, sounds like more trouble to me.
> >
> 
> I am sorry, my POV is exactly the opposite of that.
> No need to argue about it though ;-)
> 
> > Anyway, before we go further into this, what's the use case. Why
> > do you want to provide option to disable following origin for non-dir?
> >
> 
> I started thinking about this because of the squashfs bug report
> (replacing lower layers) for which I had sent a patch to automatically
> disable non-dir origin.
> 
> Reproducing the same problems with underlying fs with uuid is harder
> but not impossible to think of a scenario.
> My line of thinking is why should force feed the users with a feature they
> didn't ask for if it can break something.
> The very least we could do is allow users to opt-out.
> 
> But then again, if no one complains, we don't really need to do anything.
> I have that feature (no follow origin) anyway for snapshot, but I can enable
> it only for the snapshot case, so I don't mind if it can be enabled with
> another config option or not - just wanted to put it out there for discussion.

"origin" seems to be more of an internal detail of overlayfs at this
point of time. So I agree that instead of providing another
opetion to disable it now, we can wait if somebody really runs into
issues. And you can disable it for snapshofts internally if you really
have to.

Thanks
Vivek


      reply index

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-13 14:19 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-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
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 [this message]

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=20200716152614.GD422759@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

($INBOX_DIR/description missing)

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-unionfs/0 linux-unionfs/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-unionfs linux-unionfs/ https://lore.kernel.org/linux-unionfs \
		linux-unionfs@vger.kernel.org
	public-inbox-index linux-unionfs

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-unionfs


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git