On Wed, Jan 31, 2018 at 5:46 PM, Vivek Goyal <vgoyal@xxxxxxxxxx> wrote: > On Wed, Jan 31, 2018 at 05:38:45PM +0200, Amir Goldstein wrote: >> On Wed, Jan 31, 2018 at 5:20 PM, Vivek Goyal <vgoyal@xxxxxxxxxx> wrote: >> > On Wed, Jan 31, 2018 at 03:57:12PM +0200, Amir Goldstein wrote: >> > >> > ORIGIN behavior is little unintuitive though. Despite the fact that file >> > is not searchable through lower, it is visible through decoding of file >> > handle and it is atleast non-intuitive. >> > >> >> Maybe not intuitive at first glance, but try again: >> >> The only thing we *need* from underlying fs is to provide us with a unique >> and persistent inode number we can use for the overlay object. >> >> Even if the inode number we get from underlying fs is not in any of the >> layers, it is still a viable inode number we can use in overlay coupled >> with overlay unique st_dev, to create a system wide unique st_dev;st_ino >> tuple. > > As long as we use only inode number, it probably is still fine. > > But I look at ORIGIN as a generic infrastructure which other features can > make use of it. For example, metacopy is using it to copy up file later. > And there it will be non-intuitive that a file is not in any of the > lower, still ORIGIN was decoded and file was copied up. It can come > as a surprise to user. Atleast I was surprised when I ran into this > while testing the feature. > In context of metacopy it is indeed strange and you may need to address it somehow. In the end I see it as a security concern that can be addressed the same way as redirect_dir=nofollow. nfsd has a similar security concern for non-dir file handles. an nfs clients can get hold of a file that is no longer under the exported share or that is under a directory with reduces permissions. This is the reason for the 'subtree_check' nfs export configuration which enforces 'connectable' non-dir file handles and does ancestry check by nfsd_acceptable(). So down the road, you may want to implement metacopy=subtree_check (or something shorter) to store connectable ORIGIN xattr and verify subtree when checking origin chain. Cheers, Amir. >> >> So I don't see any reason to fix this. >> However, if one would want to fix this, that will require at least: >> 1. storing a 'connectable' non-dir file handle in ORIGIN xattr >> 2. but still use the non-connectable file handle for index >> 3. in ovl_acceptable(), check if non-dir is !IS_ROOT and validate >> it with is_subdir() same as done for directories >> >> Cheers, >> Amir. >> >> > >> > >> >> Hi yangerkun, >> >> >> >> Replying from phone so sorry for excluding list. >> >> Please add list back if replying. >> >> >> >> This behavior is expected and sort of documented in ovl_acceptable() >> >> >> >> The only property required from st_ino >> >> Is that it is unique together with st_dev of overlay. >> >> >> >> Nothing in that example breaks this requirement. >> >> >> >> The only semi problem is that when the old origin will be unlinked st_ino >> >> of overlay inode will change. >> >> That is an acceptable behavior for offline changes in overlay layers. >> >> >> >> Cheers, >> >> Amir. >> >> On Jan 31, 2018 12:36 PM, "yangerkun" <yangerkun@xxxxxxxxxx> wrote: >> >> >> >> Hi, >> >> >> >> While thinking about "origin" xattr, i find a problem which retrieval >> >> methods show as below: >> >> >> >> $mkdir lower lower1 lower2 upper work merge >> >> $touch lower1/a >> >> $mount -t overlay -olowerdir=lower:lower1,upperdir=upper,workdir=work merge >> >> merge >> >> $echo abc > merge/a >> >> $ls -li merge/a >> >> Then, we can get the ino of file a equals to the ino of lower1/a. >> >> $umount merge >> >> $mount -t overlay -olowerdir=lower:lower2,upperdir=upper,workdir=work merge >> >> merge >> >> $ls -li merge/a >> >> >> >> The ino for file a is same as file lower1/a, while there is no file a in >> >> lower and lower2. Because ovl_get_origin will get the wrong origin. >> >> >> >> Thanks, >> >> yangerkun -- 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
