> 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. Right. That is why I fixed ksmd not FUSE. > > > > 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? As you pointed out, if FUSE had additional checks for this, then the issue wouldn't have occurred in the first place. However, I believe it is not the fundamental fix since FUSE operates correctly under the sanity checks of VFS. Widely used file systems may perform such checks by themselves or might not have the functionality related to this. But if any new functionality relevant to this were added, we can expect similar problems to happen. Hobin > > Tom.
