[RFC] incorrect dosmode on stream associated with dir

Timur I. Bakeyev timur at com.bat.ru
Wed Apr 11 00:14:03 UTC 2018


On 11 April 2018 at 02:10, Jeremy Allison via samba-technical <
samba-technical at lists.samba.org> wrote:

> On Tue, Apr 10, 2018 at 07:34:42PM -0400, Andrew Walker via
> samba-technical wrote:
> >
> > Great! This is turning out to be more interesting than I thought :)
> >
> > I had same result as you when I first generated the ADS and output
> allinfo:
> >
> > smb: \> allinfo test35:ADS
> > altname: test35
> > create_time:    Tue Apr 10 13:45:00 2018 EDT
> > access_time:    Tue Apr 10 13:45:00 2018 EDT
> > write_time:     Tue Apr 10 13:45:00 2018 EDT
> > change_time:    Tue Apr 10 13:45:00 2018 EDT
> > attributes: A (20)
> >
> > Then I removed the "archive" bit from the directory.
> > setmode test35 -a
> >
> > Then I repeat the test
> >
> > smb: \> allinfo test35:ADS
> > altname: test35
> > create_time:    Tue Apr 10 13:45:00 2018 EDT
> > access_time:    Tue Apr 10 13:45:00 2018 EDT
> > write_time:     Tue Apr 10 13:45:00 2018 EDT
> > change_time:    Tue Apr 10 13:45:00 2018 EDT
> > attributes: D (10)
> > NT_STATUS_INVALID_PARAMETER getting streams for \test35:ADS
> >
> > The stream is now reported as a directory. It looks like
> > FILE_ATTRIBUTE_DIRECTORY gets written to the dir's DOSATTRIB whenever we
> > modify it.
>
> OK, I think the following is the "minimal" correct fix.
>
> Turns out vfs_streams_xattr.c:streams_xattr_fstat() and
> vfs_streams_xattr.c:streams_xattr_stat() re-use the base
> file stat info an plonk a S_IFREG bit in there without
> clearing the S_IFDIR bit :-).
>
> However I'm tempted to add your change also as a "belt and braces"
> protection :-).
>
> Now I need to go create a bug report and then add
> a test script the reproduces this :-).
>
> Thanks a *LOT* for tracking this down.
>

 	smb_fname->st.st_ex_mode &= ~S_IFMT;
+	smb_fname->st.st_ex_mode &= ~S_IFDIR;


Can be written as:

 	smb_fname->st.st_ex_mode &= ~(S_IFMT | S_IFDIR);

I believe.

With regards,
Timur Bakeyev.


More information about the samba-technical mailing list