Bug 13450 - vfs_streams_xattr: IO on stream fails once basefile is renamed
Summary: vfs_streams_xattr: IO on stream fails once basefile is renamed
Status: RESOLVED INVALID
Alias: None
Product: Samba 4.1 and newer
Classification: Unclassified
Component: VFS Modules (show other bugs)
Version: unspecified
Hardware: All All
: P5 normal (vote)
Target Milestone: ---
Assignee: Ralph Böhme
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-05-26 13:34 UTC by Ralph Böhme
Modified: 2018-05-26 15:41 UTC (History)
1 user (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Ralph Böhme 2018-05-26 13:34:01 UTC 
Share:

[test]
    path = /shares/test
    vfs objects = streams_xattr

Reproducer:

$ bin/smbtorture -U slow%x //localhost/test "vfs.fruit.read open rsrc after rename"                                                           
smbtorture 4.9.0pre1-DEVELOPERBUILD
Using seed 1526727510
time: 2018-05-19 10:58:30.032495
test: read open rsrc after rename
time: 2018-05-19 10:58:30.036265
Create file with resource fork
Open resource fork
Rename base file
Read resource fork of renamed file
time: 2018-05-19 10:58:30.107480
failure: read open rsrc after rename [
../source4/torture/vfs/fruit.c:3969: status was NT_STATUS_OBJECT_NAME_NOT_FOUND, expected NT_STATUS_OK: smb2_read failed                                                                     
]

The problem is thart the logic in streams_xattr_recheck() doesn't check fsp->base_fsp->fsp_name. Yet worse: even if it did, it wouldn't help, as in non_widelink_open() in open.c we don't update fsp->base_fsp->fsp_name like we do it for fsp->fsp_name to reflect the chdir(parent_dir).

Have patch, need bugnumber....
Comment 1 Ralph Böhme 2018-05-26 15:41:46 UTC 
Damn, looks like I never ran this test against Windows and apparently also not against macOS, as both fail the test.

Windows fails with NT_STATUS_ACCESS_DENIED, macOS with NT_STATUS_SHARING_VIOLATION. It's a pitty, as I have such a nice fix... :/

Closing this bug as invalid and eventually opening a new one to make sure we match Windows, returning NT_STATUS_ACCESS_DENIED, not NT_STATUS_OBJECT_NAME_NOT_FOUND.