On 7/5/2024 9:16 AM, Ralph Boehme wrote:
On 7/5/24 2:33 PM, Namjae Jeon wrote:
2024년 7월 5일 (금) 오후 8:54, Ralph Boehme <slow@xxxxxxxxx>님이 작성:
On 7/5/24 5:27 AM, Hobin Woo wrote:
may_open() does not allow a directory to be opened with the write
access.
However, some writing flags set by client result in adding write access
on server, making ksmbd incompatible with FUSE file system. Simply,
let's
discard the write access when opening a directory.
afair this should cause a failure like EACCESS or EISDIR and just be
ignored. What does a Windows server return in this case, or Samba for
that matter as it (hopefully) will behave like Windows.
From what I've checked the packet dump, Samba doesn't return any
errors in the same case.
Samba seems to open it with O_RDONLY if it is directory, So there is
no problem, is it right?
Hm, it seems my memory is playing tricks on me. Samba indeed forces
O_RDONLY for directories in the servers and ignores the client requested
access mask. Interestingly we don't seem to have any test for this case,
at least I couldn't find any with a quick search. Quickly putting
together a torture test shows Windows behaves the same. MS-FSA doesn't
mention any such check should be done for directories as well. Getinfo
on such a handle even returns the original unmodified client access
mask, including the write access.
Sorry for the noise! :)
-slow
I would ask to see that the SMB3 protocol test suite results are not
impacted by this change, and ideally the various Linux/XFS tests as
well. I don't see any indication these were run?
The other thing I want to point out is that the crash reported in the
commit message is a FUSE failure. Why is that not a bug, and why does
the message not justify why the "fix" is in ksmbd?
Tom.