vfs_crossrename not working in samba-4.15.*

Pavel Filipenský pfilipensky at samba.org
Fri Oct 7 18:46:06 UTC 2022


On 10/7/22 19:13, Jeremy Allison wrote:
> On Fri, Oct 07, 2022 at 04:25:19PM +0200, Pavel Filipenský via 
> samba-technical wrote:
>> I believe that the bug was introduced in
>>
>> 5c18f07 2021-06-16 21:01 -0700 Jeremy Allison     o s3: VFS: 
>> crossrename. Use real dirfsp for SMB_VFS_RENAMEAT()
>>
>>
>> which removes
>>
>> -       if (unlink (dest) && errno != ENOENT) {
>>
>> and adss
>>
>>
>> +       ret = SMB_VFS_NEXT_UNLINKAT(handle,..
>> +       if (ret == -1) {
>
> Well calling "unlink()" directly is (a) symlink-unsafe,
> and (b) means this module is completely unstackable
> and not usable on anything other than a local filesystem.
>
> So I stand by the change :-). We just need to figure
> out the locking issues.


I was not proposing to remove SMB_VFS_NEXT_UNLINKAT()  ;-) I just hoped 
that adding the removed  errno != ENOENT check will help. But it does 
not work neither with the master nor with e.g. v4-16-test . Adding errno 
!= ENOENT check in v4-16-test  leads to a different panic than in 
master. It panics in get_share_mode_lock():


#6  0x00007fa642dd4057 in smb_panic (why=0x7fa6431a2f80 
"../../source3/locking/share_mode_lock.c:891") at ../../lib/util/fault.c:197
#7  0x00007fa643058e67 in get_share_mode_lock (mem_ctx=0x556e157b56c0, 
id=..., servicepath=0x556e157b1270 
"/home/pfilipen/workspace/projects/samba/2571/st/ad_member/share", 
smb_fname=0x556e1582cb70,
     old_write_time=0x7ffdba282cf0) at 
../../source3/locking/share_mode_lock.c:891
#8  0x00007fa6430f3cc1 in open_file_ntcreate (conn=0x556e158176b0, 
req=0x0, access_mask=274, share_access=7, create_disposition=2, 
create_options=0, new_dos_attributes=0, oplock_request=8, lease=0x0,
     private_flags=0, parent_dir_fname=0x556e1582ce00, 
smb_fname_atname=0x556e1582b170, pinfo=0x7ffdba282eec, 
fsp=0x556e15737f70) at ../../source3/smbd/open.c:3940
#9  0x00007fa6430f8c6c in create_file_unixpath (conn=0x556e158176b0, 
req=0x0, smb_fname=0x556e15830cc0, access_mask=274, share_access=7, 
create_disposition=2, create_options=0, file_attributes=128,
     oplock_request=8, lease=0x0, allocation_size=0, private_flags=0, 
sd=0x0, ea_list=0x0, result=0x7ffdba2830b0, pinfo=0x7ffdba2830bc) at 
../../source3/smbd/open.c:5959
#10 0x00007fa6430f9870 in create_file_default (conn=0x556e158176b0, 
req=0x0, smb_fname=0x556e15830cc0, access_mask=274, share_access=7, 
create_disposition=2, create_options=0, file_attributes=128,
     oplock_request=0, lease=0x0, allocation_size=0, private_flags=0, 
sd=0x0, ea_list=0x0, result=0x7ffdba2832e0, pinfo=0x7ffdba2832dc, 
in_context_blobs=0x0, out_context_blobs=0x0)
     at ../../source3/smbd/open.c:6277
#11 0x00007fa64306966f in vfswrap_create_file (handle=0x556e1581d100, 
req=0x0, smb_fname=0x556e15830cc0, access_mask=274, share_access=7, 
create_disposition=2, create_options=0, file_attributes=128,
     oplock_request=0, lease=0x0, allocation_size=0, private_flags=0, 
sd=0x0, ea_list=0x0, result=0x7ffdba2832e0, pinfo=0x7ffdba2832dc, 
in_context_blobs=0x0, out_context_blobs=0x0)
     at ../../source3/modules/vfs_default.c:750
#12 0x00007fa64310590d in smb_vfs_call_create_file 
(handle=0x556e1581d100, req=0x0, smb_fname=0x556e15830cc0, 
access_mask=274, share_access=7, create_disposition=2, create_options=0, 
file_attributes=128,
     oplock_request=0, lease=0x0, allocation_size=0, private_flags=0, 
sd=0x0, ea_list=0x0, result=0x7ffdba2832e0, pinfo=0x7ffdba2832dc, 
in_context_blobs=0x0, out_context_blobs=0x0)
     at ../../source3/smbd/vfs.c:1763
#13 0x00007fa64309c7a2 in copy_internals (ctx=0x556e157b56c0, 
conn=0x556e158176b0, req=0x0, smb_fname_src=0x556e158309c0, 
smb_fname_dst=0x556e15830cc0, attrs=6) at ../../source3/smbd/nttrans.c:1630
#14 0x00007fa62e4ed05a in copy_reg (handle=0x556e157b02a0, 
srcfsp=0x556e15813650, source=0x556e1582ad30, dstfsp=0x556e157bb980, 
dest=0x556e1582be70) at ../../source3/modules/vfs_crossrename.c:115
#15 0x00007fa62e4ed1a0 in crossrename_renameat (handle=0x556e157b02a0, 
srcfsp=0x556e15813650, smb_fname_src=0x556e1582ad30, 
dstfsp=0x556e157bb980, smb_fname_dst=0x556e1582be70)
     at ../../source3/modules/vfs_crossrename.c:164
#16 0x00007fa64310615d in smb_vfs_call_renameat (handle=0x556e157b02a0, 
srcfsp=0x556e15813650, smb_fname_src=0x556e1582ad30, 
dstfsp=0x556e157bb980, smb_fname_dst=0x556e1582be70) at 
../../source3/smbd/vfs.c:1962
#17 0x00007fa6430b8090 in rename_internals_fsp (conn=0x556e158176b0, 
fsp=0x556e157c1050, smb_fname_dst_in=0x556e157b5970, 
dst_original_lcomp=0x556e157b76a0 "Q8", attrs=6, replace_if_exists=false)
     at ../../source3/smbd/reply.c:7486
#18 0x00007fa6430d7c85 in smb2_file_rename_information 
(conn=0x556e158176b0, req=0x556e15810930, pdata=0x556e15799ad0 "", 
total_data=32, fsp=0x556e157c1050, smb_fname_src=0x556e15813350)
     at ../../source3/smbd/trans2.c:7140


I have spotted this commit, that deals with something related. It uses 
as a fix a change from SMB_VFS_CREATE_FILE() to create_internal_fsp(). 
The analogy would be to change SMB_VFS_NEXT_UNLINKAT() to unlink(), but 
as you explained, this is not the way.


commit 1052314dcd05738f29d1ae85a5a4b8eaa4babe3d
Author: Stefan Metzmacher <metze at samba.org>
Date:   Wed Dec 23 11:58:08 2020 +0100

     s3:adouble: rewrite ad_open_rsrc() as adouble_open_rsrc_fsp() using 
create_internal_fsp()

     "._" AppleDouble files are hidden by vfs_fruit by default, so 
there's no
     need to go through a full SMB_VFS_CREATE_FILE() for them.

     They don't need an smbXsrv_open_global.tdb entry nor a locking.tdb
     entry, so we just open them with fd_openat().

     This avoids a recursion deadlock in get_share_mode_lock() when closing
     the ':AFP_Resource' stream.


So any suggestions how to approach the locking issues are more than welcome.




More information about the samba-technical mailing list