Miklos Szeredi:
> You misunderstand. What I think is:
>
> To be able to correctly perform permission checks based on cached
> inode attributes, those attributes may need to be refreshed before
> making the permission checks.
You seem to be replacing the problem.
The problem is more generic, not
Tomas M:
> I prefer to just mention this problem in aufs documentation, so people
> will 'stat' a fuse-based filesystem's mountpoint before adding it as
> aufs branch.
It is not enough since Miklos thinks getattr is necessary for every VFS
lookup. Of course, I don't agree.
> I don't understan
> Now FUSE becomes very special thing to me and aufs.
> For users, aufs will call vfs_getattr in case of the branch is FUSE.
I prefer to just mention this problem in aufs documentation, so people
will 'stat' a fuse-based filesystem's mountpoint before adding it as
aufs branch.
I don't underst
Miklos Szeredi:
> > It is very hard for me that they are VFS lookup bug.
>
> Why? What has the sticky check or the O_NOATIME check to do with
> aufs?
If it was VFS bug, it must be a generic problem, not specific to aufs.
While you have mentioned about the race problem, the permission check in
l
Miklos Szeredi:
> > But I could understand that you are still asserting getattr is
> > necessary even in the cases of may_open() or something, and that is a
> > VFS lookup bug.
> > Am I right?
>
> Yes :)
It is very hard for me that they are VFS lookup bug.
If they are really VFS lookup bug, you
Miklos Szeredi:
> > When you create/remove something, lookup operation involves accessing
> > inode->i_uid, i_gid, permission bits in i_mode, i_ino and i_flags.
> >
> > For example,
:::
> > - may_open() checks inode->i_uid.
>
> Yup.
>
> > - unlink(2) and rmdir(2) check the sticky bit an
