On Mon, Jan 08, 2018 at 04:42:59PM +0200, Amir Goldstein wrote: > On Mon, Jan 8, 2018 at 4:13 PM, Vivek Goyal <vgoyal@xxxxxxxxxx> wrote: > > On Sat, Jan 06, 2018 at 09:38:07AM +0200, Amir Goldstein wrote: > >> On Wed, Nov 29, 2017 at 5:54 PM, Vivek Goyal <vgoyal@xxxxxxxxxx> wrote: > >> > Hi, > >> > > >> > Please find attached V9 of the patches. Minor changes to take care of > >> > Amir's comments. I have also dropped RFC tag. If there are no concerns, > >> > then I would like these patches to be included. > >> > > >> > >> Sorry Vivek, just realized some issues: > >> > >> 1. Considering Miklos' commit > >> 438c84c2f0c7 ovl: don't follow redirects if redirect_dir=off > >> It is probably not a good idea to allow lookup of metacopy unless > >> metacopy=on. Is that already the behavior in V9? > > > > Hi Amir, > > > > Hmm.., no, that's not the behavior in V9. Remember, we wanted to follow > > metacopy origin even if metacopy=off. That way a user can mount a > > overlayfs with metacopy=off (which was previously mounted as metacopy=on) > > and not be broken. > > > > User can also mount with redirect_dir=nofollow after previously mounting with > redirect_dir=on. It's the exact same thing. > > > If we follow metacopy only if metacopy=on, then we really need some > > mechanism which can atleast warn user that this overlay mount was > > mounted with metacopy=on in the past and expect some unexpected results > > if mounted with metacopy=off. > > > > Has there been any agreement on what mechanism to use to remember what > > features have been turned on existing overlay mount. > > > > There is no agreement, but there is code in upstream that "allows" the user > to make the same with redirect_dir. The consequences of this configuration is > -EPERM on lookup. > You actually have to allow this configuration for security reasons, the only > question is whether metacopy will have 3 modes (off/follow/on) or just on/off > where off implies nofollow. Ok, I will also return -EPERM of metacopy xattr is found but metacopy=on is not set. We can introduce metacopy=follow later if need be. Right now I can't think how it will be useful. Once we have a use case, adding it should be easy as there are not backward compatibility issues to deal with. Vivek -- To unsubscribe from this list: send the line "unsubscribe linux-unionfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
