SMB_VFS_PARENT_PATHNAME

[Stefan Metzmacher]

Hi Jeremy,

I'm currently looking at shadow_copy2_parent_pathname()
and don't really understand why we have it.

All it seems to do is to call 'parent->twrp = 0' in the case
the path is already converted by any other shadow_copy2_* function.

I guess it's done in order to avoid recursion if the result of
SMB_VFS_PARENT_PATHNAME() is passed into the vfs stack again.

The changes went in via https://gitlab.com/samba-team/samba/-/merge_requests/1992,
but there are no reproducer tests nor any descriptor what the problem is.

There's only a hint to snapdirseverywhere...

Do you remember the details? I'd like to write a test for it
and then see if a different fix would also fix the problem.

I guess in all places we call shadow_copy2_convert (or shadow_copy2_do_convert())
to replace smb_filename->base_name, we also set smb_filename->twrap to 0.
With that shadow_copy2_parent_pathname() should no longer be needed.

But with removing shadow_copy2_parent_pathname() without any other change

   make -j test TESTS='samba3.blackbox.*.shadow_copy'

still passes, so there's no test for the problem.

Maybe it only triggers in some combination with other
vfs modules which call SMB_VFS_PARENT_PATHNAME() either direct or via
parent_pathref() in a recursive way.

acl_common_remove_object() for acl_xattr is one place where it potentially
matters.

stat_with_cap_dac_override() for nfs4 acls ignores parent->twrp,
so it's unrelated.

ad_convert_delete_adfile() will be used in vfs_fruit with
'fruit:convert_adouble = yes' (which is the default).
That passes parent_fname->fsp to SMB_VFS_NEXT_UNLINKAT(),
so it might also be affected...

It would be great if you have any hints :-)

Thanks!
metze