[PATCH] smbd: Fix snapshot query on shares with DFS enabled

[Jeremy Allison]

On Thu, Aug 18, 2016 at 02:09:55PM +0200, David Disseldorp wrote:
> On Wed, 17 Aug 2016 17:00:48 -0700, Jeremy Allison wrote:
> 
> > David - do you have a working Windows box exposing shadow
> > copies ?
> >
> > I'm trying to get master smbclient using the allinfo command
> > to list the snapshots available on a Windows server over
> > SMB1 using the client cli_shadow_copy_data() function
> > called from the allinfo command.
> > 
> > For the life of me I can't get Windows to reply that
> > there are any shadow copies available, even though
> > I know there are (and when I query over SMB2 it's
> > correctly reporting them).
> 
> I see the same with master and earlier smbclient releases. Was thinking
> it was due to a malformed request, after the Wireshark dissector shows
> the NTtrans Setup section misaligned by one byte (it interprets the
> first as padding). However, looking at MS-SMB 2.2.7.2.1 the request
> appears to be okay. Probably worth checking against Windows SMB1 client
> behaviour...

Found the problem. For SMB1 we need to call cli_shadow_copy_data()
*TWICE* in order for a Windows server to return results. Once with
bool get_names = false, in order to send the max_data_return as
16, which somehow primes the server to expect the second call,
with max_data_return of CLI_BUFFER_SIZE, which then correctly
fetches the data.

This is a Windows SMB1 bug - I'm guessing they never tested the
SMB1 server with a client that just tried a large enough value
to start with to prevent a round trip and their client always
does the '16' followed by whatever that returned.

The Windows SMB2 server works correctly though with one call with a
large enough value.

We still have the problem that when we create the paths previous
versions path to query the SMB1 server returns NT_STATUS_OBJECT_PATH_NOT_FOUND,
due to the fact we're not setting the flags2 FLAGS2_REPARSE_PATH
bit in the request when we're doing the path query. We don't
currently have capabilities to do that, so I'm going to create
another bug and add create fixes for all these things.

The client and server shadow copy/snapper code is a bit of
a mess. What I indend to do for master / 4.6.0 (too late
for 4.5.x) is to add a flag to struct smb_filename to
note that the path came in via a call with FLAGS2_REPARSE_PATH
set. If we don't have that we don't need to do any path
manipulation in the vfs_shadow_copy2 or vfs_snapper
layers - that should speed things up a bit.

Alternatively, now we know in the pathname parser
that we're dealing with an @GMT- path (in SMB1)
or faked-up @GMT- path (in SMB2 via the TWrp token)
then we could remove the @GMT- entry from the path
inside the filename parser unix_convert(), and instead
of a flag in struct smb_filename we could add a time_t
entry which represents the 'previous version timestamp'
this path refers to.

That might be cleaner in the long run as there are
other areas in the smbd server code above the VFS
where we do pathname manipulation (parent_dirname()
etc.) which doesn't currently know about @GMT- pathnames.

Thoughts ?