On Mon, Aug 28, 2017 at 7:20 AM, zhangyi (F) <yi.zhang@xxxxxxxxxx> wrote:
> Hi all:
>
> I notice that if the lower dir have absolute path symlink to another lower file,
> the lower origin file will be modified if we do something to this symlink in merge
> layer, such as chown or chmod. It can be reproduced as these steps:
>
> $ mkdir lower upper worker merger
> $ touch lower/aa
> $ ln -s $(pwd)/lower/aa $(pwd)/lower/bb
> $ mount -t overlay -o lowerdir=lower,upperdir=upper,workdir=worker overlayfs merger
> $ ls -l merger/aa
> -rw-r--r--. 1 root root 0 Aug 28 07:42 merger/aa
> $ chmod 777 merger/bb
> $ ls -l merger/aa
> -rwxrwxrwx. 1 root root 0 Aug 28 07:42 merger/aa
>
>
> I have an idea to resolve this problem, we can do someting in ovl_get_link(). I.e. like that:
>
> static const char *ovl_get_link(struct dentry *dentry,
> struct inode *inode,
> struct delayed_call *done)
> {
> const struct cred *old_cred;
> const char *p;
>
> if (!dentry)
> return ERR_PTR(-ECHILD);
>
> old_cred = ovl_override_creds(dentry->d_sb);
> p = vfs_get_link(ovl_dentry_real(dentry), done);
> revert_creds(old_cred);
>
> + if (*p == '/')
> + return ovl_get_link_orig(ofs, p);
>
> return p;
> }
>
> In ovl_get_link_orig(), we can deal with three cases:
> 1) Link origin belongs to the lower layer:
> Find which lower layer it belongs to, then convert absolute path to relative
> path and return. We also can save the relative path in a string to ovl_inode,
> which can get directly next time;
> 2) Link origin belongs to the upper layer:
> No problem, do nothing;
> 3) Link origin not handled by overlayfs:
> Return ENOENT errno.
>
> What do you think? Please let me know if you have some suggestiones.
>
I don't think that is a problem that is unique to overlayfs or that it should be
fixed by overlayfs.
Is it not the same behavior you would get with bind mounts and even copying
a subdir with absolute links to another location? Basically, it the problem of
escaping a container/sandbox and overlayfs is a private case.
I believe the concern, which is just, but not unique to overlayfs is supposed to
be addressed by AT_NO_JUMPS and friends (https://lwn.net/Articles/723057/).
Not sure if a mount option to enforce AT_NO_JUMPS was being considered,
but if it was, maybe setting it by default on an overlayfs mount would
make sense.
Thanks,
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
