On Wed, Jan 10, 2018 at 3:56 PM, Vivek Goyal <vgoyal@xxxxxxxxxx> wrote: > 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. > > Hi Miklos and Amir, > > Thinking more about security implications of this. > > Can a user hand craft ORIGIN xattr? I mean, if inode number of lower file > is known, can a user come up with file handle of lower and put in ORIGIN > XATTR? > > If yes, this sounds like a security concern. Then I as a user can simply > hand craft an upper file and point to any file in lower and put associated > ORIGIN and METACOPY xattr on upper and next time mount is done with > metacopy=on, I can get access to any lower file? "trusted." prefix xattrs need CAP_SYS_ADMIN, so no, it's not that simple to exploit. But if underlying layer comes from untrusted source (e.g. pendrive, etc) then that could indeed be a security concern. So, we should make sure users understand the risks associated with overlay mounting. And we'll need to be especially careful if we want to allow unprivileged mount of overlays. Thanks, Miklos -- 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
