Hi Mauricio,
Mauricio Faria de Oliveira:
> The key change is very simple (set `path.mnt` in vfsub_lookup_one_len())
> but its caller chain is large enough (reviewed/modified ~30 functions).
> Fortunately most of them already had `path.mnt` set or easy to obtain.
Thanx for the report. You made a good analysis again.
But I am afraid I cannot fully understand the problem yet. Let me make
sure a few things.
- What is the "real" trigger?
I mean the "root cause of the problem."
If your branches were tmpfs+ext4 or something, the problem should not
happen. Simple open(2) should succeed obviously. Is it because of
the writable FUSE branch?
As you might know, the behaviour of vfsub_update_h_iattr() depends
upon whether the branch is FUSE or not.
- vfs_getattr_nosec() (in AppArmor disabled case)
and
common_perm_cond() (in AppArmor enabled case),
they refer path->mnt since the commits
549c7297717c3 2021-01-24 fs: make helpers idmap mount aware
3cee6079f62f4 2021-01-24 apparmor: handle idmapped mounts
Currently I guess these commits are largely related to this problem,
and I don't agree that the bug was born 10 years ago.
Assuming the writable FUSE branch is close to one of the cause, I will
find the simplest and minimalst FUSE fs and try reproducing the problem
on my side.
ntfs-3g (you mentioned) didn't co-work well on my test environment.
Installing the package (I'm a debian user) complains about EFI brabra
and I gave up ntfs-3g.
Anyway I think I should try the old bug report on unix.stackexchange.com
you mentioned, which I didn't know, after finishing this problem.
About the patch:
Instead of adding a parameter 'struct vfsmount *mnt' to
vfsub_lookup_one_len() family, I'd rather convert the type of parameter
'parent' into struct path.
J. R. Okajima
