2017/8/28 14:43, Amir Goldstein wrote:
> 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
^^^^^^^^^^^^^^^^^^^
Correct it: $ ls -l lower/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 a lot for the answer, I will think about it.
Thanks,
ZhangYi.
--
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
