SMB Shares appear to be rename-able from Clients
This should not be possible, but it appears that a user from Windows can rename a share, which actually renames mounted directory on the SAN, but does not change any metadata on the dataset, so the dataset has one path for the mountpoint, yet the path actually changed because it was renamed, and so the mountpoint is now broken.
To demonstrate, do these steps:
On server under some smb shared zfs dataset (for instance: tank/smbroot) create a child and make it smb shared as well, like that: zfs create -o sharesmb=on tank/smbroot/childA
On windows client connect to smbroot share and inside it rename childA dir to childB. This operation will complete with success.
Now on server you have /tank/smbroot/childB dir, but all mount/share information is stale. The mount, sharemgr and "mountpoint" property for tank/smbroot/childA still point out to /tank/smbroot/childA.
Other callers of VOP_RENAME check that the source vnode is not a mount point before allowing the operation. (eg. see #7454) The SMB server, being a direct VOP caller, should do the same.
From racktop: 0e6d24b28064e21d45151c15bcafbe58fc8c8626
BSR-2045 SMB Shares appear to be rename-able from Clients
Testing done: attempted to rename share from MacOS and samba smbclient, got error in both cases.
This has been in RackTop releases for at least a couple years.
Updated by Electric Monk 3 days ago
- Status changed from In Progress to Closed
- % Done changed from 90 to 100
commit 663b59f48c396b41650fffe9e2f20a85e9710c85 Author: Alexander Stetsenko <firstname.lastname@example.org> Date: 2022-09-20T14:47:32.000Z 14986 SMB Shares appear to be rename-able from Clients Reviewed by: Gordon Ross <email@example.com> Reviewed by: Matt Barden <firstname.lastname@example.org> Approved by: Dan McDonald <email@example.com>