On Fri, Jan 5, 2018 at 6:35 PM, Vivek Goyal <vgoyal@xxxxxxxxxx> wrote: > On Fri, Jan 05, 2018 at 06:26:55PM +0200, Amir Goldstein wrote: >> On Fri, Jan 5, 2018 at 6:04 PM, Vivek Goyal <vgoyal@xxxxxxxxxx> wrote: >> > On Thu, Jan 04, 2018 at 06:40:02PM +0200, Amir Goldstein wrote: >> >> When the "verify" feature is enabled, a directory inode found in lower >> >> layer by name or by redirect_dir is verified against the file handle of >> >> the copy up origin that is stored in the upper layer. >> >> >> >> This introduces a change of behavior for the case of lower layer >> >> modification while overlay is offline. A lower directory created or >> >> moved offline under an exisitng upper directory, will not be merged with >> >> that upper directory. >> >> >> >> The "verify" feature should not be used after copying layers, >> >> because the new lower directory inodes would fail verification. >> >> >> >> Signed-off-by: Amir Goldstein <amir73il@xxxxxxxxx> >> >> --- >> >> Documentation/filesystems/overlayfs.txt | 16 ++++++++++++++++ >> >> fs/overlayfs/namei.c | 13 +++++++++++++ >> >> 2 files changed, 29 insertions(+) >> >> >> >> diff --git a/Documentation/filesystems/overlayfs.txt b/Documentation/filesystems/overlayfs.txt >> >> index e6a5f4912b6d..00e0595f3d7e 100644 >> >> --- a/Documentation/filesystems/overlayfs.txt >> >> +++ b/Documentation/filesystems/overlayfs.txt >> >> @@ -299,6 +299,22 @@ filesystem are not allowed. If the underlying filesystem is changed, >> >> the behavior of the overlay is undefined, though it will not result in >> >> a crash or deadlock. >> >> >> >> +When the underlying filesystems supports NFS export, overlay mount can be >> >> +made more resilient to offline and online changes of the underlying lower >> >> +layer by enabling the "verify" feature. >> >> + >> >> +On every copy_up, an NFS file handle of the lower inode, along with the >> >> +UUID of the lower filesystem, are encoded and stored in an extended >> >> +attribute "trusted.overlay.origin" on the upper inode. >> >> + >> >> +When the "verify" feature is enabled, a lookup of a merged directory, that >> >> +found a lower directory at the lookup path or at the path pointed to by >> >> +the "trusted.overlay.redirect" extended attribute, will verify that the >> >> +found lower directory file handle and lower filesystem UUID match the >> >> +origin file handle that was stored at copy_up time. If a found lower >> >> +directory does not match the stored origin, that directory will not be >> >> +merged with the upper directory. >> >> + >> >> Testsuite >> >> --------- >> >> >> >> diff --git a/fs/overlayfs/namei.c b/fs/overlayfs/namei.c >> >> index 46a3e31b0225..56deb2785af7 100644 >> >> --- a/fs/overlayfs/namei.c >> >> +++ b/fs/overlayfs/namei.c >> >> @@ -734,6 +734,19 @@ struct dentry *ovl_lookup(struct inode *dir, struct dentry *dentry, >> >> } >> >> } >> >> >> >> + /* >> >> + * When "verify" feature is enabled, do not merge with a lower >> >> + * dir that does not match a stored origin xattr. >> >> + */ >> >> + if (upperdentry && !ctr && ovl_verify(dentry->d_sb)) { >> >> + err = ovl_verify_origin(upperdentry, this, false, >> >> + false); >> >> + if (err) { >> >> + dput(this); >> >> + break; >> >> + } >> >> + } >> >> + >> > >> > So this will verify directory origin only for top level lower dir. Rest >> > of the lowers can still be modified offline without this code noticing it? >> > >> >> Correct, from patch 6/23: >> >> + } else if (ofs->config.verify && ofs->config.upperdir && stacklen > 1) { >> + pr_warn("overlayfs: option 'verify=on' cannot verify >> redirects from middle layer dirs\n"); > > So for non-dir case, we check origin by default and error out if decoding > of fh fails. Why not do the same thing for directories as well. I mean > why directory origin check should be hidden behind a mount option > (verfiy=). > Because it is a change of behavior so we need users to opt-in for it. When copying layers, file handles become stale. As a result, inode numbers of non-dir are taken from upper, but after copying inode numbers change anyway, so the implication is moot. You cannot say the same for copied merge dirs with origin that becomes stale. The implication of not following lower dir after copying are significant. Amir. -- 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