SMB_VFS_PARENT_PATHNAME
Stefan Metzmacher
metze at samba.org
Fri Jun 7 13:55:08 UTC 2024
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
More information about the samba-technical
mailing list